Contextual advice for new developers

Dear new developer,

A few months ago I asked Marie Chatfield, a front end developer and advice columnist, what her one best piece of advice for new developers was.

She wrote a great response. From the post:

For the self-taught programmer: I am amazed at your dedication and perseverance and ability to learn from different resources. Remember that other people have valuable things to teach you, too, and seek out trusted mentors or role models when you can. You will never stop learning in this industry, and you have shown already that you are ready and willing to put in the work. That’s going to take you far.

For the one who doesn’t see themself represented anywhere: I am so glad that you are here. I hope you can stay here for a long time. I hope you find communities that make you feel welcome and safe and included. You get to make the right choices for you and your health and safety, even if it makes others uncomfortable or disappointed. You don’t owe increasing the representation of a space with your presence to anyone. You belong here, and you should get to focus on doing the kind of work you want.

What I like most about this is that she gave contextual advice. New developers share many characteristics but are by no means a homogeneous group. The bootcamp grad who was a marketing guy previously is different than the computer science graduate who is starting her first job after college. They both differ from the kid who has been coding since they were twelve. I write these letters from a certain perspective, but know that everyone will read them from their own place.

I really also appreciated her advice to everyone:

 

  • It’s okay to fail. Everyone makes mistakes.
  • It’s okay to look things up. You don’t have to remember everything to be a good developer.
  • Everyone is nervous about interviews. They’re kind of awful. But you get through them.

 

I asked Marie for one piece of advice, but she gave more than ten. I enjoyed reading her advice to new developers and I hope you will too.

Sincerely,

Dan

PS She also has written some other great posts.

Don’t be afraid to “fail”

This is a guest post from Cierra Nease. Enjoy.

Dear new developer,

“Failures” as a new developer are plenty — but you might be asking, why is “failures” in quotes? To fail something is dependent upon one’s perspective. The only true failure is to quit working towards success. Every failure brings a small success in that you learn what the right answer is not. How can you problem solve without a way of marking off solutions that do not work? A failure is simply a solution that didn’t work at that specific time.

We can all talk about how learning and growth come from having failures, but it’s hard to remember that when you feel like you are a failure. Failures do not inherently make the person a failure, and it can be hard to make that distinction in the moment. Sometimes we need someone else to remind us of this.

I’ve had a lot of people in life reiterate this concept to me. The most recent person was a fellow developer named Mike on the Denver light rail. It’s funny what will happen when people participate in communicating and interacting with each other, but that is for another blog post entirely. For now, let’s go back to Mike. Mike overheard me talking to another passenger about being in a bootcamp. When I finished my conversation, he handed me a card and said he’d love to answer any questions I have about becoming a developer. I elaborated on some of my bootcamp experience, which happens to be full of failures.

Mike expressed his number one piece of advice for any developer, telling me: “whatever you do, don’t be afraid to fail.” We started talking about this in depth, and it really resonated with me for the rest of the evening. As a new developer, you really only see senior developers’ successes. Each developer goes through their own learning process which does include failures.

The failures that lead to success don’t stop when you become a “better” developer. If you are looking for a point when you quit failing as a developer, then you are looking for the wrong thing. The more you fail, the more you learn. The more you learn, the more you grow. The more you grow, the better the developer you become.

As a newer developer, I look forward to all of the opportunities to learn, grow, and accept my failures as the wrong solution instead of accepting them as a personal characteristic.

Sincerely,

Cierra

Cierra Nease is currently studying software development. She blogs at Cierra Codes 101.

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.

Sincerely,

Dan