Dear new developer,
This post covers some great tips on getting through your first year. It starts off ominously:
The first year as a programmer is one of the most frustrating things a homo sapien can experience. You’re thrust from the world of ambiguous human communication into the icy waters of cold, hard correctness. There is no compromise with the machine. It does exactly what you tell it to, no more, no less.
But then moves to some good advice, about advice:
There are very few absolutes when it comes to practical programming. A Technical opinions of developers are based on their experiences, the books they’ve read and the technologies they happened to work with. No one does a thorough survey of the technology landscape before declaring their support for a given tool, application or methodology.
This is so true. Everyone’s opinion is path dependent. I was a MySQL user for years and thought it was the best open source database, until a chance comment from someone I was chatting with at a meetup (see, you should attend a meetup) mentioned that PostgreSQL has transactional DDL. That is, you can alter a table as part of a transaction, and they roll it back. (Happy to report that MySQL has made progress on this, though I don’t believe they are at feature parity yet.) If I hadn’t run into that meetup participant, it is unlikely I would have learned that nuance.
Multiply that experience by the hundreds of decisions a developer makes every year based on their knowledge, their problem space and their work environment and you can see how different advice can be. And to be fair, how it can all be valid, based on context.
The post also covers ego-less coding, what to learn, and the joy of bug hunting. The whole post, “Survive your first year as a programmer”, is worth a read.
Dear new developer,
I enjoyed this post about how to learn. While the author toots his own horn a bit much for me, he makes some very valid points about how to learn. Most importantly, you want to learn using the best resource. What is best?
The best resource is a bit of a lie – it’s really just the one that’s best for you, given your prior experiences and the medium you enjoy. You’ll usually only know you found it in hindsight.
And, once you’ve gained an intermediate level understanding of what you are trying to learn, you should:
Stop. This is counter-intuitive, but unless you want to become a master at something (besides learning), you really just want to know everything at an intermediate level.
The whole post, “How to learn things at 1000x the speed”, is worth checking out.
Dear new developer,
Sometimes you have to learn or do something boring. I know there are times when I’ve had to schlep, whether that is data entry, learning a technology that I’m not thrilled about, or tediously manually replicating a bug many many times to try to debug it.
A couple of tips on how to deal with this:
- Focus on the larger picture. This often helps me stay motivated. Why am I doing this? How is it connected to the larger goals of the organization? Who is this going to help when it is finished.
- Notice the fun parts. You can’t, of course, only do the fun parts, but you can notice them and smile. For example, I am not really a front end developer. I find CSS to be a combination of both frustration and boredom, but there are times when I have to mangle it. I enjoy learning some of the basics (the difference between padding and margin). And it is often a chance to ask questions of a member of my team with different strengths than I have, which is usually pleasant.
- Automate what you can. Don’t go overboard, but you can do simple types of automation like creating a shell script or shell alias. Even just writing down the exact steps you are doing or the areas you’ve explored can be helpful. It’s helpful now to deal with the tedium (in two ways, both because it can be more interesting to write the automation than to do the work and because having the automation means you’re less likely to make mistakes) and helpful in the future in case this issue arises again for you or someone else.
- Take breaks when you need to. Depending on your deadline, take periodic breaks. If there are other tasks on your todo list that you never seem to get to but have some value, take a break and do one of them. Remember that it is a marathon, not a sprint.
- Depending on how long you’ve been working on learning this technology or task, you may want to stick your head up and make sure what you are doing is still needed. That is obviously not good advice if you have only been working on this for a few hours, but if it has been a few days or weeks, sometimes other priorities will take precedence. Be prepared to answer the question “well, how long do you have left?” with some level of confidence, though.
Sometimes you have to do or learn something that you find boring. Hopefully these tips will help make it a little easier.
Dear new developer,
This post by a Bloomberg developer catalogs everything they learned sitting next to a senior developer for a year. Lots of good stuff in there. Favorite excerpts:
How to handle an outage:
For when things go wrong, and they will, the golden rule is minimizing client impact.
My natural tendency when things went wrong were to fix the problems. Turns out, it’s not the most optimal solution.
Instead of fixing what went wrong, even if it’s a “one line change”, the first thing to do is rollback. Go back to the previous working state. This is the quickest way to get clients back on a working version.
Only then should I look at what went wrong and fix those bugs.
This is really good advice. When you are under pressure in a production outage, the tendency to try to figure out what is going on can be very powerful. However, figuring out the root cause of the issue is probably not as important as restoring functionality to your end users. Roll back. If you won’t be able to replicate the issue in your staging environment (due to load or some other reason) save off your logfiles and note the start and end times of the outage for further analysis (slack is good for that).
On code reviews:
Code reviews are amazing for learning. It’s an external feedback loop on how you’d write code vs how they write it. What’s the diff? Is one way better than the other? I asked myself this question with every code review I did: “Why did they do it this way?”. Whenever I couldn’t find a suitable answer, I’d go talk to them.
After the first month, I started catching mistakes in my teammates codes (just like they were doing for mine). This was insane. Peer reviews became a lot more fun for me – it was a game I looked forward to – a game to improve my code-sense.
My heuristic: Don’t approve code till I understand how it works.
Code review is definitely a skill worth practicing. You don’t want to nitpick and I’m a fan of automated linters/code style enforcers. That way you can have all the ‘where does the brace go’ arguments once, and then have the rules automatically enforced. Of course you can look for bad variable and function names, and that is valuable (and non automatable). But in my mind there are two aspects code review that are harder, but more important:
- How does this fit into the overall system. Are there other components that should use this code or be used by this code? Is this structured correctly?
- Do I understand this code and what it is trying to do. This means you need to understand the problem that the code is solving.
The whole thing is worth a read.
Dear new developer,
This post talks about how to ask for mentoring, but the principles apply to getting in touch with any busy person. Busy people are by definition busy, and get a large number of emails and requests every day. (Here’s a VC talking about the difference between ignoring and not replying, and how they look the same to a sender.)
The key is that you as the requester need to put in some effort. From the post:
In other words, when you asks for a busy person’s time for “mentorship” or “advice” or whatever, show (a) you are serious and have gone as far as you can by yourself (b) have taken concrete steps to address whatever your needs are and (optionally. but especially with code related efforts)(c) how helping you could benefit them/their project.
This effort on your part shows that you are serious. It qualifies you. Especially if you persist. (Now, you can’t persist to the point of annoying the person. There’s a line between persistence and bugging someone. I always preface any email I send to someone asking a favor with ‘hey, feel free to tell me to buzz off’, and I mean it.)
I hate to sound all zen master-ey but in my experience, it is doing the work that teaches you what you need to do next.
That doesn’t mean you can’t learn from reading (otherwise why have documentation or even this blog!) but that you need to actually try things outlined in docs. Even just typing the commands of a tutorial (instead of copying and pasting) will help you understand what you are doing.
The whole post is worth a read.
Dear new developer,
Monica Dinculescu, who works at Google, has some good advice for new developers. I don’t agree with everything she says (ah, the cacophony) but some of it definitely resonates. She has a unique approach to an AMA (ask me anything) using GitHub issues.
My favorite answer was to this question:
Sometimes I feel like I’m not good enough to become a professional software developer
I think you’re putting too much pressure on yourself! Feeling like you’re not good enough is so standard in life it even has its own name: impostor syndrome. All the developers I know, myself included, have on countless occasions thought everyone else was better than them and they just accidentally got lucky. We’ve all been stuck on a problem for days, only to randomly discover a solution after a while, out of nowhere. I find stepping away from it or talking to people helps a lot! I also do this super annoying thing to my co-workers where I explain to them, out loud, the problem I have, but by explaining it to them I end up thinking about a solution. (this also has a name, it’s called rubber ducking!). Anyway, it just takes time and practice to become confident!
We all have difficulties. I remember lying down in my home office, struggling with one of the hardest problems I’ve ever faced (it was how to update a partial recurring reservation for a piece of equipment if the room reservation changed), and thinking “there’s no way I can do this”. I also remember interviewing in March of 2018 and feeling like “man, I am so out of date and useless”.
The joy of technology continually evolving is that I get to learn all the time. The downside is that I feel continually out of date. Chances are you might too. Remember, if it was easy, we would have automated it.
I hope you enjoy all of Monica’s advice.
Dear new developer,
I suggest that the first job you take be the one with the highest learning potential, not the highest earning potential. (This post contrasts the two, in the context of entrepreneurship.) This can vary depending on your skills and needs, but I’ve seen over and over again that you learn more with one or more team members than you do alone. Other technical people working on the same problems, even if they are new as well, will elevate you.
They’ll bring a world of difference that you can learn from, including (but not limited to):
- technical tools
- understandings of the problem
As you work with them, try to understand where they are coming from and appreciate it, especially as it relates to solving the problem. Building this empathy for others is really really important.
Now, what can you do if you get hired and are the only technical person on staff (either as a contractor or employee)? Luckily, understanding others and building empathy doesn’t just work with developers, so you can work on that aspect, even though the problems and language may be a bit further from your comfort zone. As far as learning differences in technical tools, I suggest you join a meetup or an online community or both.