"Breadcrumbs" and the new Etsy Search Analytics Tool
Etsy recently released a new tool that displays data about where your traffic is coming from. Breadcrumbs is a tool that captures this data into a CSV file.
New Etsy Feature!
If you’re an Etsy seller, you may have seen this new search analytics tool when you’re logged in. This tool provides valuable information about how users found your Etsy page.
The only problem: there is a lot of data!. If you’re trying to capture this data, this is a copy/paste nightmare!
Look at the pagination!
You can see that there are several pages that are out of view. Since I want to see all this data at once and work with it outside of this page, I needed a way to grab all this data without doing copy/paste for hours. Enter: “Breadcrumbs!”
The Companion Tool: Breadcrumbs!
Breadcrumbs is a tool that interacts with the Etsy Search Analytics section of your Etsy backend to extract all the data into a single CSV file.
It is built in Applescript and Javascript and is run while your Etsy Search Analytics section is open in your Safari Browser. For more information and to give it a try, visit my GitHub project!
the "Learn to Code" Era
With applications and websites becoming more complex, learning how to code has never been more important. But is that enough, or even the right focus?
Academia and the private sector have been taking notice of the large demand for a workforce that knows how to write code; offering online courses, weekend workshops, and revamping their on-campus curriculums.
With applications and websites becoming larger, more complex, and mobile device friendly, knowing how to write code has never been more important. But is that enough, or even the right focus?
Don't get me wrong, I am all for people to learn this skill. In fact, I'm very passionate about furthering inclusivity and transparency around this industry. While many things are "open", there is still a mystery layer.
That layer is what I'm going to focus on here. That layer is comprised of soft and hard skills that are required to actually write code in the real world.
Problem Solving
In my years as a developer, I've touched many different languages. HAML, SASS, LESS, CSS, HTML, JS, Ruby, Java, XML, JSON, PHP, ASP, Python, C#, and the list goes on. Some of these languages, I've had to work with more than others, but the point is that I've had to work in all of these languages at some point. Why? I approach development as a problem-solver. Not as a syntax master.
When I'm solving a front end code problem, my stream of consciousness often sounds something like this:
How does this thingy get populated to the front end? And this text over here changes when this doo-hickey gets changed, why is that?
I'm not saying that learning the vocabulary is not important. It definitely is! However, it's not as important as being able to understand how things work and are able to apply problem-solving skills. The vocabulary and syntax familiarity will come with more practice. I promise!
The point is: I don't know the syntax of all those languages I mentioned. <sarcasm>Shocking, I know. </sarcasm> I do, however, love a challenge, and the internal reward of solving them. Also, you'll notice that I was asking questions. That's really important.
Asking Questions
It's not always easy to ask questions. To some degree, there is always a fear of coming across as a "noob", or worse: "an idiot."
I can't count the amount of times in the beginning of my developer career when I would ask a question, and the recipient would get annoyed with me. This made me apprehensive about asking any further questions, which led to a lot of wasted time and energy!
This fear would result in wasting a ton of time trying to figure out something that could have been answered quickly.
After spending years facing this fear, I finally developed enough practice to stop letting it get in my way. In fact, the more questions I asked, the more I learned (It's great how that works, isn't it?)
I'm not saying asking questions is easy. There is a set of skills that go into asking questions.
Be aware of timing and be empathetic of their workflow so as not to disrupt them
Know when to be self-sufficient and when to ask questions. "Timebox" solving the problem before asking someone else if you feel it is something you can figure out on your own.
Pay attention to how you communicate with your team. Some people prefer direct, concise communication; while others prefer a more conversational approach.
Know the right person to ask. Pay attention to the type of responsibilities held by each member of your team or office. This takes time, but if you have an org chart, learn it!
You might be thinking this is in the realm of "overthinking" especially for something as important as asking questions. There is no "right" way to ask questions. However, I do think that is value in being mindful of your team. If you allow empathy drive your approach, your team will appreciate it and your efforts will pay dividends.
"Learning to code" is only one small piece of the puzzle
I take issue with the notion that coding is the path to becoming a higher-value contributor to an agency, or as a solo-entrepreneur.
To be fair, "Learn-to-Code" curriculums have come a long way. However, I still don't think there is quite enough focus on the value of learning how everything works.
I think it's dishonest for private sector businesses to make it seem like coding is the main value proposition that will "lead you to an awesome job in no time!"
When "simple" isn't "simple"
Let's say you want to learn how to build websites. Most paths will start you with learning how to write HTML and CSS.
You learn all the building blocks that make up a "valid" HTML page. That's great and all, but once a student learns what goes into making it a "live" thing on the internet, eyes typically gloss over.
Why the blank stares? Outside of the coding part, these skills (mostly) are required to build the most basic website.
DNS Management
Deployment Methods
Domains
Version Control
Local Server Configuration
Task Runners
Command Line
Markup Preprocessors
I acknowledge that these type of skills are taught somewhere down the road in these curriculums (whether they are taught in the correct order is up for debate.)
Accept that you can't learn everything
The fact is, nobody can know them all front-to-back perfectly. Each technology has enough depth to be a life-long discipline. So I would argue that it's more important to be adaptable and generally know how things work than to be hyper-focused on memorizing the syntax. Naturally, there will be a set of disciplines that will interest you, which will lead to learning the syntax.
my gripes
While I have my concerns about the industry and how some businesses lure potential students, I think the movement to educate our workforce with the skills needed to contribute to our workforce is very important.
As of now, there's nothing to stop businesses from luring students (customers) with a rosey narrative about how code is the answer to your career woes and that it's "easy."
Traditional academia isn't designed to keep up with this space, so it's up to us to continue to educate, inform, and paint and accurate picture of what the industry is like and how to be successful within it.
I think people deserve to know what they are getting into before they invest a ton of money, time, and energy.
There's hope
I've found that there are many truly great places to learn about various coding languages. The UI and UX of these tools are awesome, and most of them are free! Most of these learning platforms use gamification to enhance the learning experience, which makes the whole experience more fun!
To name a few:
TLDR;
When you're faced with clever marketing that promises that "code will land you an awesome job," it's OK to be excited about it. Know that learning to code is one of many skills required to succeed and that even the things that are "simple" have many layers.
Developer Productivity
I've been writing code for nearly ten years. I'm still pretty slow, but I've learned how to get the most out of my productivity.
I've been writing code for nearly ten years. I'm still pretty slow, and I still have trouble writing code for more than three hours at a time (unless I get really motivated). The one thing I have learned in my years of writing code is how to get the best out of my productivity.
Timing
Many studies have shown that your mind is at its best in the morning. While I fought this tooth and nail at first (I'm naturally a night owl), I realized that this was true when it comes to writing code. I always tackle the toughest coding puzzles first thing, and save the easier ones for later in the day.
Taking Breaks
Again, there are many studies to back up the validity of taking breaks. I'm here to tell you that it is essential! I like to set milestones for myself when working through a coding problem. An example mental milestone.
Get through the styling for desktop viewport and ipad landscape, test it, then take a break!
Sometimes breaks came in the form of getting up to go to the bathroom, get a cup of coffee, or go for a walk. As long as it involved not being in front of a computer screen and sitting down, I considered it a welcomed break.
Making a todo list
I like to feel accomplished at the end of a day. If I don't have a set of to-dos completed, I may as well have played Battlefield all day (which would be awesome, but not exactly productive). I use teuxdeux to write a ton of mini tasks.
In addition to feeling accomplished at the end of a work day, this process of writing granular to-dos is practice for writing good project estimates.
Rewarding yourself
After I solve a really tough coding problem, I usually let out a big "F### YEAH!". Which as you could imagine, did not go over well in an open floor plan environment. Reeling in my enthusiam became a regular exercise for me at Vodori due to the environment. So I had to come up with ways to reward myself that didn't involve loud expletives.
When I conquered a tough problem, I would tell myself that I'm going to get something delicious for lunch. Or that I'm getting a beer after work. Or I would allow myself an hour or two of xbox one (again, Battlefield FTW!). The ritual of giving myself something to look forward to has really worked for me, and I think it will work for you too!
Bullet Proof Development
Think outside of the immediate requirements and anticipate how the user could interact with the component and build fail-safes for those edge-cases.
What is "Bullet-Proof Development?
First of all, nothing is truly "bullet-proof." I know my code will never be perfect and I'm always trying to improve. However, I believe there are methodologies that can reduce the number of vulnerabilities in your code.
My definition of Bullet-Proof Development: a method of building components for the web in a way that can accommodate most contexts outside of project-specific requirements. A key part of this methodology is to think outside of the immediate requirements, anticipating how the user could interact with the component and build fail-safes for those edge-cases.
What prompted this idea?
At Vodori, I was leveraged primarily for my HTML/CSS/Responsive expertise. I floated across many project teams, in and out of sprints patching up styling bugs. So many of these bugs could have been prevented with Bullet-proof development methodology.
What makes it "Bullet-Proof"?
This is not a new concept. Everything I know and practice is a culmination of knowledge of industry leaders. "Bullet-proof development methodology" is not about over-engineering, or accounting for every edge-case. It's more about minimalism.
Minimalism?
I started my career as a graphic designer. Terms like "gestalt", "visual weight", "minimalism", are examples of some of the vocabulary of that world that are very applicable to web development.
The term "minimalism" was one that always stuck out to me. Most likely because it is so widely applicable in contexts beyond the work I do every day. The concept of stripping things down into their most core with the goal of telling the story more effectively really resonated with me.
Minimalism plays a big role in Bullet-Proof Development (we'll refer to it as "BPD".) When I'm looking at a component, let's say; a button, the first thing I do is go through my BPD checklist:
- Does this work in IE8?
- Is there anything here preventing this from working in all the major modern browsers?
- Are there any unnecessary rules? If so, delete them (with caution, of course)
- Can I do this same thing with fewer rules?
Needless to say, even a "small" styling issue goes through a number of mental filters. I cringe when I hear "it's a quick styling issue, it shouldn't take any time to fix."
There's no such thing as a "quick" styling issue
On the surface, cleaning up little bugs like overflowing text in a container seem innocent enough and not very time-intense. However, little bugs like this end up reaching more people outside of the developer. Let's look at my workflow at Vodori:
- QA analyst is looking at a feature.
- QA analyst realizes that the text of a button is overflowing a button due to too many characters.
- QA analyst creates a bug ticket and writes acceptance criteria for the ticket. This includes how to create the defect, an example page where the defect occurs, and what the correct result should be.
- QA analyst assigns a bug ticket to a developer.
- Developer receives the ticket.
- Developer branches off of the project-appropriate git branch.
- Developer fixes and tests the bug.
- Developer submits the branch to be reviewed by a tech lead in a pull-request.
- Tech lead reviews the code in the pull request and initiates any communication with the developer if needed.
- Tech lead merges the branch into the stable branch (develop, usually)
- Tech lead executes a build to a QA environment
- Tech lead assigns the ticket back to the QA analyst.
- QA Analyst reviews the ticket and marks as resolved, or documents if the defect still exists.
That's three people involved, two of them at much higher billable rates than developers (usually). All this could have been prevented with some thought investment. "What happens if this button has a lot of text?" Those 12 steps (give or take a few based on your organization's workflow) and hours of cumulative time would have been saved.
TLDR;
When we are under pressure to work quickly, we as developers can get hyper-focused on the immediate requirements of the feature and lose sight of the bigger picture. If we can take a step back and think more broadly about the implications of our decisions, we could potentially save a significant amount of time, money, and sanity for our clients and ourselves!
Communication > Coding
As I progressed as a developer, I found myself spending more time with communication than coding.
Being a developer is more about communication than about writing code
When I worked at Vodori, I found that as I progressed as a developer, I was spending more time consulting, writing requirements, communicating with my team, writing documentation, and writing test acceptance criteria than writing actual code. The communication part of development consumed more of my time than writing the actual code. Why? Because communication is more important than the syntax because it is what aligns the work with the client's goals.
It took a few years of writing a ton of code to get comfortable with the front-end stack. I still really struggle to remember the seemingly endless nuance of Javascript! I think there's this period of learning that needs to happen before many of the soft skills come as much into focus. That being said, I strongly feel I would have benefitted from integrating these soft skills and higher level ways of thinking earlier in my career.
Learn to be flexible
When we talk about flexibility, we are usually referring to learning new languages and technologies. While this is very important, a good developer is also flexible in the sense of how they collaborate.
There will be instances where you're working with other developers with differences in opinion on how to implement a feature. That's natural! However, your ability to see their point of view, while defending yours, and moving toward the common goal of meeting the project or client's goals is very important.
Empathy is important
Having empathy is critically important to success as a developer. You're going to be frustrated with Project Managers imposing unrealistic deadlines without your consult. It's the nature of the business and is unavoidable. When this happens, try to educate them on why the task is unrealistic, and work on a solution together. Don't just blindly accept it and stew about it. This leads to burn-out and resentment (I lived this and learned from it!)
It's important to step back and put yourself in the shoes of your team, and your client from time to time. Understand that Project Managers, Business Analysts, and business owners have a lot on their plates too. There are aspects of their disciplines that you don't understand, just as they don't understand yours! Educate each other, and learn to be empathic.