Mistakes Are Forgiven, Hiding Them Is Not

Dear new developer,

We all make mistakes. Yes, this is not news, but it’s worth repeating.

We all make mistakes.

I have made them, you have made them, your boss has made them, the person you are interviewing with for the job you really really want and need has made them.

The one thing about mistakes is: never never hide them.

Now, that doesn’t mean you should hang every mistake out on your blog or your LinkedIn profile. Just because we all should tell the truth doesn’t mean you should say every sentence you think.

But the people who need to know about your mistake should. Who needs to know depends on the scale and scope of your mistake. If in doubt about who needs to know in a professional setting, ask your mentor, your immediate supervisor or a trusted team mate.

Don’t take your time to do this. When you discover a mistake, you should immediately do the following:

  1. Confirm it is really a mistake. You don’t want to be the boy who cried wolf. So avoid making a mistake about a mistake. Take a look at the mistake from several different perspectives.
  2. Think of a plan for fixing the mistake. This may entail bringing in other team members, depending on the severity of the mistake. It may entail shutting some things down so a mistake doesn’t get worse. There may be an immediate plan to fix the emergency and a longer term plan to prevent the emergency from happening again (perhaps using an automated test).
  3. Think about who is affected and the scope of the impact.

Finally, tell who is affected about the issue and the plan to fix it. This may in itself require some planning.

It’s very uncomfortable. When I was at a startup and was writing billing software for clients, there were times when I made a mistake. I remember one time when I had to email or call each customer whose billing I had screwed up. It sucked. But they understood and appreciated the transparency and honesty.

What is the alternative? Hiding your mistakes and pretending they never happened? This means that you don’t get to learn from them. Your users or boss may discover the mistake on their own and bring it to your attention in a far more unpleasant manner.

Making mistakes is fine (though try to not to make the same mistake twice). Hiding them is not.

Sincerely,

Dan

Consistency Is Key

Dear new developer,

Sometimes you just have to grind.

It’s easy to find yourself beaten up. Development, while not physically difficult, can be mentally and emotionally taxing. Screwups can be big. You’re typically on the sharp end of the stick when it comes to building something. Sometimes you’re part of a team, but often you’re working on something that you have insight into that no one else knows quite as well. So they can give you advice, but not definitive action. (If you work at a place where your manager is telling you how to do your job in minute detail, there’s a word for that–micromanaging.) Deadlines loom. You’re often learning on the job. Figuring things out. There’s always a new technology or framework or language or technique or term to learn.

Phew. It can be tough. Not digging ditches tough, but tough none the less. It’s easy to get discouraged and think you aren’t making any real progress.

But, just showing up and making the effort every day is often enough. I was talking to another senior developer the other day and we agreed that there is so much innate built in knowledge that you gain over the years. Things like how to navigate the command line in the most efficient way possible. How to read a regular expression. When to ask a question and when to keep going with the problem you are working on. How to ask for a raise. How to google. How to scan logs. Keeping your head in a crisis.

This stuff can’t be taught, it has to be learned. And that means showing up every day.

And this is true of any skill you want to gain. Do you want to be really good at design? At writing? At public speaking? Find some way to practice what you want to do every day or every week. A timeframe of about six months is the minimum to commit to anything serious. This is a nice amount of time because it isn’t insurmountable (who can’t commit to something for only half a year), yet you’ll be more than a beginner at the end. And then you’ll have the context to know if you want to continue the effort.

The tough thing about consistency is the opportunity cost. Committing to say, writing a blog post every week means you’ll have less time to watch your favorite TV show. It also can be scary to commit to something. What if I choose the wrong technology? What if I don’t like writing a blog? Good news–you can stop. Especially early in your career, you can take a mulligan pretty easily, because you’re being hired for potential rather than skillset.

The great thing about consistency is that it gives you a chance to improve and the permission to fail. If you are working on hard problems (for you) every day, you can’t expect to hit a home run every time. Heck, you can’t expect to hit a single every time. But you can show up, put in the hard work and you’ll improve. If you write a blog post every day for a year, some will be good, some will be bad, and some will be horrible. But even if only ten percent are good, that’s still more great content than twelve awesome monthly blog posts.

I’ve found that having a printed out calendar can be a big help when trying to be consistent. I print out the calendar and put a big fat X every time you do something. Especially if I am trying to do the task daily, getting to put that big X on the calendar has motivated me, sometimes even forced me out of bed.

Keep it up.

Sincerely,

Dan

Programming Is Terrible, So Learn To Enjoy It

Dear new developer,

I appreciated this post which talks to people who are interested in being a developer, rather than someone who is newly a developer. I still think a lot of things apply.

This especially resonated:

…programming is terrible, so learn to enjoy it. If you are “on the net” learning about what programming is like, listening to the voices that get the most attention, you are probably getting the “Hollywood version” of what it means to work with software day in and day out. Now don’t get me wrong, I love programming. My best days are when I can take off the many other hats I wear and just focus on a development project and writing tests to go with it. But, it’s not all roses, and you should be prepared for that.

Here are some things that are terrible about programming (and counterpoint).

  • The tool set is always changing. What you learned two years ago may or may not be useful to you now. But some technologies age better than others, and you always have a chance to learn something new.
  • There are two modes of development that are radically different (deep thinking and communication), and you have to switch between them constantly. But you get to do deep thinking!
  • Error messages don’t make sense. But Google can help with that. And so can you, by blogging about the error after you figure it out.
  • With modern applications, there’s a ton of complexity and you can’t possibly understand everything. But you can put together an amazing application that would have taken a team of developers by yourself or with a small team.
  • Sometimes, you may be the expert in your problem, which can make it hard to find help. I remember writhing on the floor trying to figure out one of the most difficult problems I’ve ever solved (figuring out an editing interface and rules for recurring events on a calendar with child events that needed to have different durations than the parent event) and realizing that I could ask no one about it. But, you get the chance to be an expert!

Of course, every job has its warts. And development is no different. But programming and development are in a rapid state of flux. This means that you must (and get to) learn every day.

Sincerely,

Dan

Beware Of Your Arrogance

Dear new developer,

I wrote this post years ago, but it still applies today.

Ah, the arrogance of software developers. (I’m a software developer myself, so I figure I have carte blanche to take aim at the foibles of my profession.) Why, just the other day, I reviewed a legal document, and pointed out several places where I thought it could be improved (wording, some incorrect references, and whatnot). Now, why do I think that I have any business looking over a legal document (a real lawyer will check it over too)? Well, why shouldn’t I? I think that most developers have a couple of the characteristics/behaviors listed below, and that these can lead to such arrogance.

Just because you are good at something valuable (development) doesn’t mean that you are good at everything. I was blinded in my youth because I was good at asking questions, paid attention to details, and was good at creating logical constructs in my head. That is helpful in so many contexts.

But it is also true that almost every profession has as long, if not a longer, sense of history and as big, if not a bigger, well of knowledge than software development. So beware that your ability to probe, ask questions and solve problems doesn’t inadvertently (or worse, intentionally) dismiss the learning of other professions.

On the flip side, domain expertise (through lived experience or study) and software development is a powerful combination. You can model software such that end users can speak in the domain. You’ll be closer to understanding their problems.

Another issue with arrogance is that when you’re sure you know the answers (or have the right way to find them), you don’t listen to other people as well.

I was very happy to charge forward with whatever solution I thought made sense, and that led to suboptimal solutions. Both in the coding sense and in the sense that you have to bring people along. The best coded solution in the world won’t work if people won’t use it. So listen to your users and make sure you fully understand their worldview as best as you can before you charge ahead implementing solutions.

Sincerely,

Dan

Egoless programming

Dear new developer,

This post is worth reading in full, but is advice that holds for all developers, not just folks starting out.

I especially liked

Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.

and

You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

But all of them are good. Go on, go read it.

Note that these principles (though not the post) are from a book published in 1971. Technology changes yet people remain the same.

Sincerely,

Dan

Work through the first month of trepidation

Dear new developer,

I remember the first month of my first job. I wasn’t sure who was who, what was what or even why was why. It was hard to find tasks that I felt helped the team. I wasn’t sure what words people used off-handedly meant. I’d read and re-read instructions, fearful that I wasn’t “doing it right.”

Every day was a struggle.

Eventually, I learned my way around. Around the code base. Around the organization. Around my tools. Around the team.

And everything got better.

And then I switched jobs and it happened again. The trepidation, I mean.

Yes, it was a bit easier, because I had previous experience to look back on. But I still needed to learn a ton to be effective at job #2. Eventually things got better.

And then I switched jobs and it happened again. The trepidation, I mean.

See a pattern? For every job I ever took, the first month was tough. You just don’t know, and worse, you don’t know what you don’t know. And even worse, you’ll often be hired into a company that is moving fast, so you may have a hard time finding someone to teach you.

There’s no easy solution, but there is a solution. Recognize that this will happen. Put your head down and do the work. Take one day at a time and celebrate your successes each time you leave work.

  • “Today, I learned how to deploy to our QA environment.”
  • “Today, I fixed two bugs and characterized a third.”
  • “Today, we were in a meeting and I made a meaningful comment.”
  • “Today, I figured out who the Docker experts are.”

And, soon enough, you’ll break through and find your way. Promise.

Sincerely,

Dan

Be a great developer today

This is a guest post from Tim Tyrrell. Enjoy.

Dear new developer,

New developers are making mistakes. They are making mistakes every day. As a new developer, one’s job is to recognize one’s mistakes, implement a change in behavior, and help others implement that same change when similar mistakes bubble to the surface of one’s awareness.

Software has clearly identified patterns. Observer, mediator, singleton, bridge, and abstract factory to name a few. Some patterns that are less popular include active mentoring, maximizing pairing interactions, and self-imposed code review. These patterns represent a few of the necessary actions required to fast-track one’s rise from junior to mid to senior and beyond. We are all guilty of exhibiting some of the best and worst behaviors as new developers— myself included.

Say Yes to Everything

This may seem daunting, but it will force a new developer to continue to claw at the boundary of their own comfort level.

They might ask: “How can I say yes to a task if I’m not sure if I can actually accomplish said task?”

Generally, software developer === problem solver. One isn’t required to know everything when one walks in the door, but one is expected to leave work each day having laid a few more bricks on top of an ever expanding foundation.

One way to level-up quickly is to say yes to tasks that managers either (a) do not have time for or (b) assign to test one’s level of grit and determination. This will show superiors that one has the bandwidth for complex assignments and that one is willing to accept challenges outside of the expected range. Time spent carrying out these tasks is less important than clearly communicating progress, outlining steps taken towards accomplishing the tasks, and reaching out frequently to resources at one’s disposal in order to avoid impasse.

Once a developer begins to set a precedence for clear communication, progress, and accomplishment, managers and senior developers begin to trust that developer at their word, and they take setbacks as a sign of high complexity or fluid acceptance criteria rather than a gap in skill-set or effort level.

Does one’s team participate in local developer meetups? Have they asked you to come along or give a talk on a project one recently completed?

Say yes.

Are one’s peers interested in a hack-a-thon this weekend?

Say yes.

Does a recruiter want to talk to the new developer about a position that might be a good fit?

Say yes.

Not that interested in the position?

Say yes.

Not that interested in the company?

Say yes.

Interviewing is a skill that needs to be practiced like any other to achieve mastery. Better to improve this skill before one is in need of utilizing said skill.

Do Not Waste the Time of Senior Developers

Developer time is consequential and incredibly expensive. When a developer with more seniority takes the time to pair with a junior they are undoubtedly losing time they could be spending doing a number of other tasks that are all vital to the health of their team. Before asking for this highly valuable time, I encourage new developers to ask themselves a few questions.

  1. Do I clearly understand the components at work and how they interact in the system in question?
  2. Have I spent ample time reading about the nuances of my problem on Github, StackOverflow, Medium, and other outlets? Did I google my error message?
  3. Am I making assumptions that I haven’t been able to prove? Have I written any tests to prove these assumptions?
  4. Have I replicated my issue multiple times, so that I can clearly outline my process when the time comes to explain it to the senior?
  5. Have I taken time to write out my current questions and investigate them on my own?
  6. Have I asked relevant questions on our messaging medium — generally Slack — and taken time to investigate answers provided to me in this written medium?
  7. Have I taken a break, walked around, done some push-ups, absorbed some sunlight, and come back to this problem with fresh eyes?
  8. Have I clearly identified the gaps in my knowledge and exhausted all other resources on my quest to fill these gaps?

Each of these questions probably deserves its own article, but developers — myself included — have ceaseless amounts of work to do and a limited number of hours in the day.

One must understand how the pieces of the puzzle fit together and communicate at their synapses. What is each piece’s objective? Is it doing too much? Have I identified the failure down to the line number?

Do this before asking a senior for their time.

All of the previous questions lead us to researching our problem on the internet. If we are not first googling the error message and reading about prior encounters, then we can certainly improve our debugging process by doing so.

Do this before asking a senior for their time.

Assumptions have plagued me mightily in my first few years as a developer. They have been at the center of many of my mistakes. Writing tests represents a fantastic way to test assumptions at a fundamental level of input and output of specific methods. If one’s team doesn’t have any tests around the components one is interacting with, then add them. If one does have tests, then run them and use them to help step through the code and check the data at each intersection.

Do this before asking a senior for their time.

We must make sure we can clearly replicate behavior numerous times or at least replicate inconsistent behavior until it becomes inconsistent. If the process is large and requires many steps then start writing them down. It is possible that one’s process is the problem. This feeds back into avoiding assumptions. Do this to ensure that the maximum amount of time can be spent analyzing the problem in question instead of searching for the unknown problem.

Do this before asking a senior for their time.

Don’t ever be afraid to ask questions. But ask them in an order similar to this: 1. Ask the internet. 2. Ask oneself. 3. Ask the internet again. 4. Ask a developer that worked on the code most recently. 5. Ask in the team messaging channel dedicated to questions.

Do this before asking a senior for their time.

Get up from one’s desk. Go for a walk. Talk to other developers near the water cooler. Don’t stare mindlessly at a screen during this time.

Do this before asking a senior for their time.

Check and make sure steps one through seven above have been carried out. Still have questions? Go ahead and make sure that one can clearly articulate every step in the process necessary to explain the problem at hand.

Now, and only now, should one ask a senior for their time.

Be On Time and Be Present

Every meeting, event, stand-up, or retro takes up precious developer time. It’s a new developer’s job to gather the maximum amount of information available, ask questions to clear up confusion, and add input where they have it. If a new developer shows up late then that developer is a disruption instead of an addition.

Let me tell all new developers a secret; they aren’t valuable enough to be distractions. Don’t be one — ever.

Use these meetings to show initiative and communicate clearly. Do not allow one’s distractions to eventually become a nuisance for other team members. Eliminate distractions and engage completely with the team and with the current discussion.

Engage Fully in Code Review

This begins with reviewing one’s own code with precision, accuracy, and a level of criticism reserved only for oneself. Where did one make trade-offs? Comment on that line and explain why the code was implemented in this way. Where did the new developer choose performance over readability?

Start the conversation.

Own the work.

Explain why.

If one isn’t aware of the why around these decisions yet, then be prepared to be taken to school by the senior developers until one does understand.

When the new developer code reviews their own work then they once again save time for those spending their precious attention and finite cognitive energy reviewing that code in the future. Follow conventions. Check that one’s CI/CD build passed. Do not ever ask for the time of other developers without a thorough pass through from oneself.

Add a video to the PR that show’s the functionality that has been developed. Show one’s test suite running. Show the level of detail needed to be a great developer.

Review the team’s pull requests. Ask questions about code that doesn’t make sense, but not before asking the internet.

Ask about patterns.

Ask about performance.

Ask about refactoring.

Ask about trade-offs.

Ask about testing.

Ask about anything that doesn’t look like it’s been written with the utmost care. This will push one’s teammates to improve and iterate upon their work, and they will thank one for it as they level-up.

Start Mentoring

“But Tim, I’m the one that’s new here. I need more mentors! Not the other way around.”

The above statement represents a faulty mindset within many new developers. One of the most efficient ways to solidify one’s skills as a new developer is to explain known skills to others who have yet to master them. This leads to personal mastery of the subject being taught. The subject can be related to environment, shortcuts, workflow, data types, performance, logic, tools, and just about anything else.

I guarantee the foundation of a new developer’s knowledge includes skills that even seniors do not possess. Share these skills with fellow new developers and expand both network and knowledge within this process.

Did one go to a boot-camp or university to acquire one’s skills? Go mentor students.

Spend at least an hour a week doing this.

Is one in a boot-camp or university currently? Mentor more junior students.

Spend at least an hour a week doing this.

Is there anyone more junior or at a similar level — within a year — of experience at one’s current workplace? Pair with that person and offer them one’s help whenever they ask for it.

Spend at least an hour a week doing this.

Giving back will not only help a new developer achieve mastery and network expansion, but it will also help them experience happiness via altruism. This type of happiness compounds over time, and it will lead to fulfillment one never imagined.

Start Making Changes Today

Don’t wait to be a great developer. Be a great developer today. Then be a better developer tomorrow. Then share the secrets of success with other new developers.

Imagine the world that we can build together with this mindset.

Please reach out to me personally if I can help with one’s developer journey.

Be kind.

Learn hard.

Do good.

Repeat.

– Tim

This post was first published on Medium.

Tim Tyrrell is a Software Engineer at Crownpeak and Current Mentor and Mod-0 TA at Turing School. He is also a Game of Thrones conspiracy theory enthusiast/Repulsed by Flat Earth conspiracy theorists/Pun loving guy/Helper of people willing to put in the work.