What is HackerNews’ Best Advice to New Developers

Dear new developer,

I have previously written about joining an online tech community. My personal go to right now is Hacker News. I find it has a nice mix of tech, startup/business and other interesting content for me.

Here’s a thread from a few months ago with advice for junior developers. Here are a few of my favorite pieces of advice.

Lots more good stuff, including hundreds of other comments. Worth a read.

Sincerely,

Dan

Writing Is An Undervalued Engineering Skill

Dear new developer,

This post discusses writing and how learning to write well can really level up your engineering experience. You can also view over 300 comments about this post on one of my favorite online communities, Hacker News.

The author has some suggestions on how to become better:

So how can you work on becoming better at writing? Writing clearly, concisely and in a way that is easy to read? As with every skill, it’s a matter of being aware of the fundamentals, practicing, getting feedback and repeating.

I haven’t read the books he suggests for the “fundamentals” (yet), but I agree that practicing, getting feedback and repeating are crucial. It’s why I think that a blog is such a great way to spend your time.

But I think it points to the larger issue, which is that writing well is a scalable way to communicate, and that communication is at important as writing code. If you writing the wrong code, you might as well not have written anything at all.

Worth reading the whole post: Undervalued Software Engineering Skills: Writing Well.

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

Avoid being an expert beginner

Dear new developer,

This post by Erik Dietrich covers the situation where a developer becomes an “expert beginner”. This is something to avoid as you build your career–don’t work in a place where you are isolated or unable to progress. He breaks progress in any area down into a number of components–Beginner, Advanced Beginner, Competent, etc.

As such, Advanced Beginners can break one of two ways: they can move to Competent and start to grasp the big picture and their place in it, or they can ‘graduate’ to Expert Beginner by assuming that they’ve graduated to Expert. This actually isn’t as immediately ridiculous as it sounds. Let’s go back to my erstwhile bowling career and consider what might have happened had I been the only or best bowler in the alley. I would have started out doing poorly and then quickly picked the low hanging fruit of skill acquisition to rapidly advance. Dunning-Kruger notwithstanding, I might have rationally concluded that I had a pretty good aptitude for bowling as my skill level grew quickly. And I might also have concluded somewhat rationally (if rather arrogantly) that me leveling off indicated that I had reached the pinnacle of bowling skill. After all, I don’t see anyone around me that’s better than me, and there must be some point of mastery, so I guess I’m there.

This post is worth reading in whole. It resonates with me because I’ve spent most of my career in small companies. I do that because it fits best with my desires and my life goals. But I’m acutely aware that as I become more experienced, I am typically one of the most experienced technical folks in the room. This is a problem, because I could believe that I had most or all of the answers based on my experience (what the Expert Beginner believes).

I strenuously combat that by engaging with my peers in person and online, and I think this is a great way to do so. It’s not as deep an engagement as working with them, of course, but affords me the ability to work at small companies.

Ways to engage with the larger software community include:

The work environment you are in is a great place to level up, but depending on your situation, you may end up with few people you can learn from. In that case, it is imperative that you improve yourself through engaging with the larger software community.

Sincerely,

Dan

How to read code

Dear new developer,

Reading code is much more common than writing code. Some might even say, “don’t trust any documentation, read the code,” though I consider that to be a pretty radical position.

But how can you effectively read the code. This post from selftaughtcoders.com gives a good explanation:

Find one thing you know the code does, and trace those actions backward, starting at the end.

Rinse and repeat.

It’s a wonderfully self-perpetuating cycle: you read more code; you gain the ability to understand it quicker and more effectively; so you are able to consume even more code; and so on.

And it doesn’t stop there: you’ll also see huge positive gains in your own coding.

I know nothing about his courses, but his insight into reading code to build intuition about programming and development in general is spot on. I tend to do this through code reviews, reading blog posts and going to meetups rather than tracing code paths, but reading code can be a good way to level up. Github is your friend.

Sincerely,

Dan