Get used to failure

Dear new developer,

I was chatting with someone I met at a meetup who was about to graduate from a bootcamp. I asked him what his advice to a new developer would be. He said that it would be “get used to failure, and get used to working through it.”

I thought that advice was great.

I often tell colleagues that “if it is easy, someone would have already automated it”. This means that when you are working on a software problem, the problem by definition hasn’t been solved within your organization (that you know of; I’ll come back to that). This means that you’ll most often be failing. Just like scientists who try to narrow down their scope of inquiry so they can have useful experiments, you’ll try to narrow down the problem and pattern match and research so that you can have a working solution. But just like the best planned experiments fail, so will you, often.

There are two additional complexities that software developers have that scientists do not.

The tools that software developers use are themselves software and are being developed. Imagine trying to build a house when the hammers and saws that you are using are themselves changing at a rapid pace. This means that the solution that may have worked in the past is suboptimal.

And the real world that scientists operate on and try to understand doesn’t often change daily. The business world that software developers operate on and try to understand can change on the whim of a person in authority. This is an essential complexity of software development.

This experience requires you to get used to failure, both at the micro and macro levels. And to keep going. You just need to be tenacious and realize that you’ll solve the problem. Also, recognize the frustration and realize that everyone is going through it. A coach once taught me that running is hard for everyone, whether you are running a 5 minute mile or a 10 minute mile. The same is true for development. Learning something new is difficult and frustrating, whether it’s your first programming language or the intricacies of a build and deployment process that is new to you.

Get used to failure and remember that everyone else encounters it.

I mentioned I’d return to the caveat that problems you tackle haven’t been solved “that you know of”. Back in the dark ages before the internet was widespread, distribution of software knowledge was slow and driven by email, bulletin boards, journals and books. Now we have google and stack overflow. This helps with coming up to speed on external software that will help you solve problems. I’ve yet to see an internal system that works well for sharing knowledge, but it is incumbent on you and your teams to search out solutions within your organization.

Once you have a problem defined (even partially), resist the temptation to dive in and start building a solution. Rather, pop your head up and ask around and see if anyone has solved your problem. Or even one third of it. You may or may not re-use their solution, but it will inform your solution even if you don’t.



Write that down!

This is a guest blog post from John Obelenus. Enjoy.

Dear new developer,

Even when I was a kid in school I hardly wrote things down. That’s why we had textbooks after all! I was baffled by other students in college furiously transcribing every word that came out of the professor’s mouth. Now I have a career in the world of software where we track everything. Git holds all the code commits, email is never really deleted, and project management and issue tracking tools keep track of what we’re doing and have done. How could anything go missing?

I constantly looking for things and cannot find them. I get a bug report, look at the code and say to myself “That is obviously wrong, let’s fix it.” I look at the offending commit that introduced the bug (of course it was me). But what is not there? The reason for the change. So I look at the project management tool we use. And someone definitely asked for a change, but, I’m still not sure why. So I search through my email for the few days before I made the change, and…nothing. I still cannot really figure out why we all decided to make a change which introduced a bug.

Or, worse yet, someone asks for a change. All well and good. Then a month later, someone asks to change it back. So you shake your head and make the change. Then someone is confused why this is happening, and calls a meeting and invites you to help figure it out. What are you going to bring to this meeting? Did you write anything down? I never used to. Now I do.

Now I have a notepad next to my laptop. And I have a notebook on the shelf. I make better use of git messages and write down who asked for changes. When working on a feature, or a bug, and find something…“interesting” I make a Github wiki entry explaining it. I write a comment in the code base explaining it. There are two kinds of documentation — useful documentation, and redundant documentation.

No doubt many people have told you to comment your code. I hope many people have told you never to comment a loop with // loop over the array. That is not increasing clarity, its just duplicating what the code is doing. Adding noise, not signal. My contention is that comments are rarely useful for explaining “What this code does…” but rather, explains “Because of X, we are going to do…”.

Future you is going to be very happy if you start documenting the intent behind what you’re doing. Good code is easy to read. Bad code is capable of being understood with time. But code doesn’t tell you why you’re doing all this work in the first place. Maybe something has changed and you don’t even need this code anymore — deleting code is the most satisfying feeling. But you won’t know unless you know the intent, the purpose, of the code. And the rest of the folks you’re working with are going to be very happy as well.

If you write everything down (and make it public), they won’t need to tap you on the shoulder when you’re in “The Zone” to ask. When someone wants to set a meeting to understand why things are “The Way They Are” you already captured that information. You can send them the link and kill the meeting (Ok, maybe killing meetings is more satisfying than killing code).

We only have so much time in our life, and we already work long hours. Let’s make future us happier by writing things down, so we don’t have to figure it all out again. We figured it out once when we wrote the code. So capture the knowledge in that moment in time. And Write It Down!


John Obelenus

(Previously published at Medium)

John Obelenus solves problems and saves time through software and crushing entropy



Be a Just in Time Learner, part II

Dear new developer,

I previously wrote about being a JIT learner and talked about it in the context of a Just In Time compiler.

Just in time has another meaning, that relates to manufacturing. Delivering the right parts to the right plant at the right time revolutionized manufacturing. Just in time learning means that you focus on what can give you the greatest bang for your buck, and that you learn it when you need to.

The world of software is immense and as you navigate it more, you’ll begin to see patterns. When I see a new dependency management tool, I know it’ll operate roughly like the three other dependency management tools I’m experienced with. It will have:

  • a dependency tree, likely stored in text
  • a central repository or multiple repositories, where common code resides
  • a way to have a private repository for proprietary code
  • commands to update individual packages or an entire system

So, I don’t really need to master each dependency manager, because I can do the mental mapping between the ones that  I know (like maven and bundler) and the ones I’m less familiar with (composer, npm). I learn just enough to do what I need to do. I do this to avoid being overwhelmed by each new tool.

In a similar manner, you can apply the same thing to software development in general. When you start to get overwhelmed, you can focus on one task at a time, and learn just enough to do that task. Now, I think you should try to understand why you are doing that task and not just copy pasta code, but there’s a balance to be struck. You also may need to have a deep stack to do this (watch out for yak shaving), as you’ll be pulled from one task you don’t fully understand to another.

The way to defeat this is to continue to build the mental model. Try to understand the smaller pieces of a site or application before moving up to the medium size pieces and then to the larger pieces.

An example. When I’m starting a new project the first task I always try to understand is how do I get this running locally. Running a project locally is glorious! Even if the project isn’t under version control, I have absolute control of the local environment and can tweak and break things with abandon. The next task I try to understand is how does this software get deployed to production. Here obviously I can’t break things with abandon, but I learn what the architecture is like. Finally, I’ll try to make a small change and see if I can get through the deployment pipeline. This assures me I know how to connect the two key environments (local and production).

You can do the same thing with the first months of a new job. Map it to other jobs or schooling you’ve had. Think back to what worked in the past for learning new tasks.

In short, be a just in time learner. Focus on what’s in front of you, and learn that. Build models between what you know and what you don’t. Don’t fall into the trap of trying to understand everything.





What is fulfillment?

Dear new developer,

Stephanie Hurlburt tweets some amazing stuff. Definitely worth the follow.

Here’s an interesting post from her about fulfillment. From the post:

I threw myself at helping others and was absolutely shocked to find myself not really that fulfilled from this work. I couldn’t figure it out, was something wrong with me?! I upped the amount of people I was helping, started doing even more work– was it the wrong kind of work? I tried different kinds. Wasn’t helping others my mission? I felt dismayed and empty.

Sometimes what you think you should be doing is wrong. The post has some thoughts about how to tease out what you really want to be doing.

It’s always worth some time to think about where you are going. But it can be overwhelming. I asked my father about that once, and his advice was to pick one or two constants you wanted in your life and orient yourself around them. I have found that to be a great way dealing with the paralysis of choice that can affect you in modern society.



Be a Just in Time Learner, part I

Dear new developer,

There’s the concept of a JIT compiler. I was first introduced to it with the HotSpot Java compiler. The idea is that a compiler can look at code and find the code that executes often and optimize it, sometimes compiling it down to faster code, sometimes unrolling loops. I’m no compiler expert or even intermediate, but the results speak for themselves. JIT has spread elsewhere (python, ruby, javascript).

As a new developer, you should be a just in time learner. Just like the compiler watches to see what is used often and then optimizes the code that runs fast and often, you should do the same. That’s why I recommended you learn version control and a text editor. These are tools that, as a software developer, you spend a lot of time in. So learning them well will save you time in the long run.

But what about the intricacies of a language or framework. That’s important too. But it depends on how often you predict the issue will come up.

Here’s a great chart from XKCD.

If you spend two hours remembering how to do something but you only do it yearly, and you learn it well enough to do it in one hour, you save five hours over five years. Does this make a lot of sense?

So, basically, I’m saying optimize for the things you do often. Another way you can do that is to make what you learn do double duty:

  • When you learn SQL you learn a way to query across multiple different databases.
  • When you learn javascript, you are learning a language that you can use on the front end (in the browser) and the back end (on the server).
  • When you learn vi keystrokes, you can use them to edit a text file in a terminal on any unix machine, on the command line to navigate your history and directory structures, and in eclipse or visual studio.



Always Be Journaling

This is a guest blog post from Brooke Kuhlmann. Enjoy.

Dear developer,

Of the many techniques you’ll pick up over the course of your career, one worth investing in early is journaling. Journaling might not seem like a worthy endeavor at first. Capturing important moments of your life on a daily basis might even seem like extra work on top of everything else you are juggling in your life but, in time, journaling will pay dividends if you stay disciplined and detailed. As you grow older, the details of earlier experiences will grow foggy in your mind. Being able to reconstitute past experiences in order to apply to them to present situations will help you make more informed decisions.

Additionally, journaling serves a dual purpose as it makes you a better writer. This is a wonderful skill to have which shouldn’t be underestimated. In addition to technical expertise, being able to express your thoughts succinctly, supported with documented details, is a sought after skill. Inadvertently exercising this part of your mind, on a regular basis, will allow you to keep this skill sharp.


How you organize your journal entries is up to you. Everyone is different and there is no right or wrong way to do this as long as it makes sense, is easy to add new entries, and can be searched through quickly. To start with, journal entries are meant to be chronological, so it does help to use a date/time structure. Example:

Format: <year>/<month>/<day>/<hour>/<minute>/<second>
Example: 2018/12/01/10/10/10

Use of categories (for high level organization) and tags (for associations across categories) can be helpful too. Useful categories to start with could include:

  • Work – Lessons learned from paid work. In addition to the benefits of helping you stay organized and not let important ideas slip through the cracks, this also serves as a way to measure the pulse on how you are feeling about the work you are doing and the progress being made. When you look back over time and see a rocky or downward curve, it might be time to move on to something new. On the other hand, the use of your journal might be motivational, can serve as a reminder to explore previous ideas in greater detail, and can even help solve current problems.
  • Side Projects – Lessons you want to capture related to open source software, hobbies, etc. that might be worth sharing in a public forum at some point but currently is raw material.
  • Personal – For private thoughts and ideas of use only to you. This might include your health, mood, personal reflections, relationships, etc.

As for tags, you might want to use a single tag or multiple tags in order break down journal entries beyond high level categories. Tags make it easier to search for entries faster when, for example, you have a Dotfiles project you’ve been working on and you have it tagged as dotfiles too. Using multiple tags helps connect related journal entries across categories which is another nice way to group related information.

It never hurts to have a few tools to ease this organization of your thoughts. Here are a some recommendations:

  • Bear – Supports macOS, iOS, watchOS. Has great sync capability between desktop and mobile, hybrid Markdown support, and tends to be a more free form in that you can organize and tag information however you see fit. It’s free to get started and $15/year to add pro and sync features.
  • Day One – Support macOS, iOS, and watchOS. Tends to be more specialized for journaling but isn’t always the easiest to manage. It’s free to get started but $35/year for pro features.
  • Notes – Native to macOS and iOS, provides a free solution for gettings started which sync capabilities.


Choose a schedule, for writing journal entries that you are comfortable with. I would recommend at a minimum, to journal daily, even if briefly. It’s up to you to be disciplined about this as as only you will benefit. You can schedule this as a recurring action in your task manager or as a calendar event. Use whatever best fits your workflow and be diligent about it.

In addition to scheduling, you can capture important events as they occur such as thoughts while in a meeting or when working on complex technical issues. Yes, a journal can also be a helpful scratch pad for further reflective and refined thought later. If real-time journaling isn’t sufficient, try scheduling an end-of-day reminder to reflect on the day’s experiences.

Automation, as mentioned earlier, is key to being successful so figure out what works best for your mind and mode of operation. Here are some tools worth adding to your toolbox:

  • OmniFocus – Based on David Allen’s Getting Things Done book. It can cost over $100 when you buy the macOS and iOS versions but syncing is free. It’s a powerful tool and worth the investment.
  • Fantasical – If task managers are not for you, consider investing in a good calendar software and setup recurring events/reminders that way.
  • Reminders – Doesn’t have a lot of bells and whistles but will definitely help get you started until you outgrow it. Free for macOS and iOS.


In order to learn from past mistakes, experiences, and build upon earlier lessons it is important to review and reflect and on your progress. A good rule of thumb is to conduct this kind of “self retrospective” weekly, monthly, and yearly. This’ll help keep where you have been and where you are headed in perspective. Plus, it’s nice to see how far you’ve come or gone off the tracks in case you need to pivot and course correct.

Personal Results

Over the years, maintaining a Pensieve so-to-speak has made me:

  • A stronger writer – As mentioned earlier, since I’ve been journaling, I’ve found I’ve become a much stronger when writing Git commits, responding to group chat responses, creating pull requests, replying to emails, etc. I find my content is structured and well composed rather than short, terse, or staccato.
  • A stronger learner – When capturing and reflecting on the various experiences of your past life you can see connections that weren’t there before. It’s fascinating when I reflect on past work and realize I’ve forgotten a tool or technique that I didn’t fully understand at the time. Now I have much more knowledge and context for how to apply that to the current situation and thus have saved myself additional time.
  • A stronger mentor – When you accumulate a lot of experience and expertise, you can forget what was the source of your tacit knowledge. I’ve found being able to search for and share recorded knowledge so others may learn and grow in a similar manner helps make you a fount of information.

Closing Thoughts

Your future self will thank your past self for recording this history. Being able to understand the long tail of your work — and therefore your life — is valuable in making informed decisions on what actions you’ll take next. Mine this information often because your experiences are gold.



Brooke has been developing software for ~20 years with an emphasis in the Ruby and Elm languages. He lives and works from his home office in Boulder where he enjoys the many bikes paths and close access to ski slopes. When not working on open source software or hanging out with this novelist wife, he can be found speaking at conferences on the Git Rebase Workflow or attending the various local meetups: Boulder Ruby Group, Front Range Elm, or Denver Modern Web.

Start a blog

Dear new developer,

A blog is free (except in terms of time), forces you to think, provides an example of your ability to discuss concepts, and helps others.

What’s not to like?

The hardest part about blogging is just doing it, day in and day out. Now, I am no Fred Wilson, who has blogged every day for 15 years, but I have blogged since 2003. I’ve written at least once every month of those 15 years (except one).

I can tell you that blogging won’t give you a job, but it can occasionally lead to contracts. That it won’t make you a superstar, but can give you credibility. That it won’t make you an excellent writer, but that it will polish your ability to convey thoughts in text.

What should you write about? Write about the latest problem you faced at work the technology that interests you or a comment on a link that you found. It doesn’t really matter as long as you can write about it and can commit.

Because it is the commitment that matters. The benefits of blogging don’t accrue on the first or second post, but on the twenty first or twenty second.

I can’t speak highly enough of blogging. I tell everyone I meet to start a blog. I’m suggesting you do too.




Help your manager help you by owning the one to one agenda

Dear new developer,

You need to realize that your manager is pulled between two goals (this assumes you have a good manager–if you don’t have a manager who wants to help you, find a new job).

1. Helping you.

2. Helping the company for which you work.

Unfortunately, the latter takes precedence. It’s more work (because it includes helping everyone else out) and higher priority.

So what can you do? Make your manager aware of how they can help you. This doesn’t need to be done in a demanding manner, but you need to make sure you are heard. So, for instance, mention that you are exploring or have been reading about a new technology like machine learning, and really want an opportunity to use the skills professionally. Realize that you might not get exactly what you want (if you are working for a webdev shop, you won’t get a chance to build compilers). But if you don’t ask, your manager won’t know your career interests.

I like one to ones for this purpose. These are regular meetings (once a week to once a month) for a short period of time (30 minutes to 60 minutes) where you control the agenda. It’s not a status report or a troubleshooting session. Instead, it’s where you can ask questions and inform your manager.

Things I’ve learned in one to ones (all at different jobs):

  • a colleague wanted to go to clown school
  • I was managing as I wanted to be managed, not as a report wanted to be managed
  • a colleague’s spouse had a long commute and that a move was imminent

All of these were helpful to me in assessing the health of a team, planning for change and understanding the person. These are really what a manager should be focusing on.

Next time you go to a one to one, think about what kind of questions you need to ask or what kind of conversations you need to have to make sure your manager can help you. Here’s a list of topics that might help jump start the conversation.

If you don’t have a one to one, set one up. If your manager is resistant, find out why, and see if there is something less formal, but still regular, that you can set up. Maybe you just need to calendar a regular reminder to yourself to stop by the manager’s office. If you don’t have regular lines of communication with your manager then when things get tough, you’ll have a hard time having conversations that will help both parties. The trust and ease that regular contact builds is key for defusing a tough situation, or at least de-escalating it.



Don’t be afraid to ask questions

This is a guest blog post from Noel Worden. Enjoy.

Dear new developer,

Don’t be afraid to ask questions. It can be stressful and humbling to reach out and ask a question, but it can be the best way to stop spinning your wheels and make progress. It’s stressful because as a new developer you are trying to prove yourself to your peers and superiors. It’s humbling because you are admitting to someone that you don’t know something. Giving consideration to when and how you ask a question can make for a much smoother interaction.

So, how long should you grind away at a problem before you concede and reach out for assistance?  That can be a tough call, and can differ quite a bit based on your situation. Some aspects to consider are:

  • Is this meant to be a learning experience?
    • If so, you’ll want to spend more time looking for the answer before reaching out to anyone
  • How long do you have to complete the task?
    • The more time you have before the task is due, the more time you should spend looking for the answer yourself
  • How busy is the rest of your team and/or your mentor?
    • If no one has the time to help you unfortunately don’t have many options other than to stick it out and try to find the solution yourself until you see an opportunity to ask for help
  • Is the sticking point something relatively ‘small’ and holding you up from the bigger task?
    • Is it something like a bug in the project setup, or a hangup of a similar nature, that doesn’t have anything directly to do with the task? These types of hangups can be difficult to Google, or solve by experimentation, and are scenarios where asking for help earlier than later is probably a good idea.
  • Have you worked through other aspects of the task?
    • Sometimes skipping over the sticking point and working on other pieces can lead to an ‘aha moment’.
    • It can also help to gather multiple questions and therefore get multiple answers from one help session.

Once you’ve decided to reach out for help, the phrasing of the question can be important. When I ask a question I often try to go over what I’ve already tried, what I’ve Googled, and then what exactly is stumping me. This shows that I’ve made a solid effort to solve it myself, gives the other person as much context as possible, and helps avoid the person giving you assistance to not repeat the same unsuccessful troubleshooting attempts.

Most importantly, above all else, don’t be afraid to ask questions. Everyone was a new developer at one point in their career, and asking questions is a legitimate way to learn.



Noel Worden started his career as a photographer, shifted gears to become a cabinetmaker, then graduated from the coding bootcamp Bloc. He is currently working as a software engineer for MojoTech in Boulder, Colorado.