What Every Developer Should Learn Early On

Because it is a StackOverflow blog post its a bit self-serving, but basically it appears to advocate creating a permanent intangible dependency on StackOverflow to your ability to program.

Those heavily invested into StackOverflow means it becomes part of their programming identity, and as a result it skews their perspective of what they decide programming should be (which is true for them themselves).

The virtual-connectedness we have as programmers now has changed/accelerated (and perhaps thus slowed) the way programming is done. To be fair cut and paste programming has been around pre-Stack Overflow and even pre-WWW - it just required enough programmers and code-base to be in the one location for it to become viable.

As the web ages, like a sprawling codebase not rigorously maintained, the amount of cruft it acquires over time goes up - where a lot of stuff that is no longer used or out of date or just plain wrong yet still there comes up in your search.

It makes me think a lot of signal vs noise and worse still false signal vs noise comparisons. Sometimes you can find years later after you did something that you solved the problem the old/should be obsolete way, or you did the almost-the-right thing but not the right thing - often at a time/place you can't go back and correct/amend your previous code, not least because you're not meant to be working on it anymore even if you're with the same employer.

This is one of those guys I see everywhere who jumps in the middle of every flamewar and calls both sides stupid because every single conflicting topic on the face of the universe according to them is apples and oranges. It's a niave worldview.

The world is full of apples and oranges and also some apples are better than some oranges and many apples are rotten to the core.

Haskell vs. JavaScript two different world views. One language is pure liquid bs, the other is guite good. Which one? The world is complicated enough that if you search hard enough you can find a trade off somewhere,... Nonetheless the fact of the matter still stands... In aggregate with all features accounted for, one of those languages is really bad, the other is much better. Please don't be that guy.

While I agree that lines of code is a poor metric for basing decisions on, all the suggested altenatives in OP are very subjective.

Just to be controversial, the biggest thing I disagree with is the number of hours people code. Hmm... That's not exactly true. I agree with the statement that few people code more than 4-5 hours a day. What I disagree with is that you shouldn't try to put your self in a situation where you can exceed that.

There is a lot of communication that is necessary in programming. That communication takes time. However, there is a lot of communication that is unnecessary, but that still takes time. Being efficient with communication means that you can spend more time coding.

I big part of that is working on smaller teams. Some tasks are inherently separable -- they don't require a lot of communication in order to complete. Some tasks are not. Frequently teams are built on the premise that the work is separable. You'll have 100 (or even 1000!) developers working on the same thing, and the assumption is that this will speed development. Often it is not true. Often it means that you are spending 80-90% of your day coordinating with others.

There is a certain amount of communication that is necessary when you are getting requirements. One of the places where we can be inefficient at communication is with these requirements. There is a balance between getting enough information to be able to start writing code and spending your time building fictional descriptions about what you are going to build. If you spend too little time doing up front analysis, you will end up spending a lot of time iterating to your goal. If you spend too much time doing up front analysis you will strangely end up in the same situation -- the thing you thought you wanted to build turns out to be wrong because it's hard to test your assumptions without having the real thing to test it with. Knowing how to surf between these two extremes will dramatically reduce the amount of time you are spending -- and will ultimately reduce the number of conversations you require.

I will say, having worked on a lot of different kinds of teams, that if you are not spending the majority of your day writing code, then there is a problem. You should try to solve that problem. Even though writing code is tiring, it is also fun. There is nothing wrong with finishing for the day and feeling like you don't want to write code. It's a good feeling. Go home and spend time with your friends and family. Get some well deserved rest and then go back to work the next day for some more fun.

The last thing I would say is that sometimes people feel like if they aren't typing, then they aren't programming. Typing is only a very, very, very small part of programming. Even if you wrote on average 1000 lines of code a day (which would be quite a lot, no matter what you say about LOC metrics ;-) ), you aren't going to spend more that an hour physically typing it in. Almost all the time you are programming, you are either reading code, or thinking (or both). When I talk about increasing the amount of time you spend programming in your work day, I don't mean increasing the amount of time you spend typing. You might not even increase the number of lines of code you type. You might even reduce the number of lines of code you type (if you are really going well). What I'm talking about is increasing the amount of time you have to think about your problem. Even if that's thinking aloud with a pair programming, or mob programming, or getting advice from someone -- it's all good. But you should have the feeling that you are doing something that is directly adding value to what you are working on. As programmers, we are there to put the rubber to the road. We aren't primarily paid to organise, or prioritise, or argue, or negotiate, or produce status reports (whether written or oral). We are primarily paid to advance the project in directly measurable ways -- there is more appropriate functionality at the end of the day. Anything that is stopping you from doing that should be viewed with suspicion.

This is what I wish all starting developers would learn ;-)