
What Every Developer Should Learn Early On - kjhughes
https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/?cb=1
======
partomniscient
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.

------
crimsonalucard
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.

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

~~~
tanseydavid
Lines-of-code is not a metric without a "per" something.

If someone told you that you were about to join a team that tends towards an
average of about 6-7 thousand lines-of-code PER METHOD, would you consider
this fact in your decision to join or not join this team?

------
mikekchar
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 ;-)

