
Things I’ve learned in 20 years of programming - galfarragem
https://daedtech.com/5-things-ive-learned-in-20-years-of-programming/
======
carl_sandland
Some things I've learned after 35 years;

    
    
      1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.
      2. question all assumptions.
      3. there is no silver bullet (read mythical man month).
      4. fight complexity and over-engineering : get to your next MVP release.
      5. always have a releasable build (stop talking and start coding).
      6. code has little value in of itself; only rarely is a block of code reusable in other contexts.
      7. requirements are a type of code, they should be written very precicely.
      8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.
      9. release as frequently as possible, to actual users, so you can discover the actual requirements.
      10. coding is not a social activity.

~~~
amake
This is unreadable on mobile.

~~~
thdrdt
I'm also having a hard time swiping the text. So ahead of the poster:

1\. learn how to communicate: being a good developer requires as much (more?)
social as it does technical skills. I would recommend formal training and
practice.

2\. question all assumptions.

3\. there is no silver bullet (read mythical man month).

4\. fight complexity and over-engineering : get to your next MVP release.

5\. always have a releasable build (stop talking and start coding).

6\. code has little value in of itself; only rarely is a block of code
reusable in other contexts.

7\. requirements are a type of code, they should be written very precicely.

8\. estimation is extrapolation (fortune telling) with unknown variables of an
unknown function.

9\. release as frequently as possible, to actual users, so you can discover
the actual requirements.

10\. coding is not a social activity.

------
johnwheeler
I’ve been programming professionally for 20 years too.. What I’ve learned is
there’s no end to the “architects”, “mentors”, “coaches”, “team leaders” and
“know it alls” who want to condescend and tell me how to do my job.

20 years of programming has taught me to avoid working with people who take
themselves so seriously and think they’ve figured it all out. 20 years has
taught me the importance of compromise, give-and-take, and following as much
as leading. It’s also taught me that there are people who’ve only been doing
this for half as long that are 10 times better.

~~~
purple_ducks
Don't forget the self-described "thought-leaders".

Oh you've been ~programming for ~3 years and you're now a thought leader -
fantastic delusion.

------
carl_sandland
This is not the best advice I've ever read, some of it smacks of "silver
bullet" thinking. For example, it's sometimes better to duplicate than couple.
Within the same component sure don't copy pasta. Also I think TDD is frankly
ridiculous; I've seen many teams spending more money on gold-plating test
lines of code than actual code. I've seen other, better teams spend all their
efforts on full integration testing only. There are no golden rules, it's just
hard work.

~~~
dogcomplex
You're in good company with Jonathan Blow and, it appears, John Carmack. Teams
pushing TDD might be a good smell test for whether they know how to
efficiently code.

~~~
cjfd
Until you mentioned him I had never heard of this Jonathan Blow character. The
thing is both of these people seem to do game development. If you write code
that is close to the hardware and needs every ounce of performance there might
be a point to this. It would make applying TDD both harder to pull off and
less beneficial.

When one is writing complex logic that is supposed to receive both frequent
new features and keep working correctly there is nothing that beats TDD.

Let me attempt to compare this to bowling even though I know nothing about
bowling. If you just occasionally like to go out bowling you can use whatever
technique you like and you will get better if you just bowl a bit more often.
If you want to play bowling on the national level you may at some point have
to drop the technique that you made up yourself when you started out. You need
to go through the uncomfortable stage of learning a new an better technique
and temporarily be worse at it. I think the people not doing TDD are just
refusing to go through this because there is not much of an objective standard
of quality for developers. We are in a field where code that lacks any sort of
quality is standard and where breaking features three times a week is
standard. TDD will fix these things.

~~~
3fe9a03ccd14ca5
TDD works great when the requirements are known and there’s little mystery.
Waterfall methods oddly enough lends themselves well for TDD, which is kind of
associated with hip styles like agile.

The reality is most projects start as exploration. What you’re thinking might
not even be possible. Can you even approximate the classes you’ll need yet?
For these scenarios TDD fits in awkwardly.

I prefer to do a little back and forth. A little dev. When things are looking
stable, a little resting. Towards the end a lot of testing.

~~~
ellius
I've found the opposite. When I start to write a test, I often realize I don't
know exactly what I need to do because the requirements are unclear or somehow
conflict with some other assumption of the system. That realization prompts me
to go talk to my product owner, which forces them to clarify their
requirements and target a more coherent idea of what the system should be.

------
cryptica
I like TDD but it should be adapted to the project. For some projects, I only
do integration tests, for others, I only write the unit tests for one or a few
of the more complex modules and test the whole system manually then if needed
I will add more tests later after the project code has settled.

It depends on a lot of things; such as what kind of complexity the project's
modules are prone to (algorithmic complexity or integration complexity), team
size, security requirements and reliability requirements.

It's very important to keep the testing as minimal as possible at the
beginning. Sometimes minimal means a lot, but you need to be able to justify
it because tests (especially unit tests) lock down interfaces and
functionality and this can go against agile principles. If your project is
innovative and requires that agility.

After 15 years experience coding on many different projects and companies,
what I learned is that blanket statements are often unhelpful. You need to
critically evaluate every case as unique and make arguments about why and how
your case differs from the norm (and it usually does).

~~~
mixmastamyk
Agreed, I don’t write a lot of tests until happy with the design. When that
solidifies it’s time to get cracking on the unit tests.

~~~
Flemlord
I have a variant on this. I start with a bullet-list of functionality I think
I’ll need. Then I write one test each for items that could impact my
architectural choices. Once I finish that first pass I go back and flesh out
each item with multiple tests as necessary.

Flushing out the architecture early is the trickiest part for me. Occasionally
I miss a seemingly-simple feature that ends up requiring an architecture
change. If this happens late in the process, I may pay for the oversight with
hours of refactoring.

------
curiousfiddler
From my ~15 years of experience, if there is just _one_ advice I could give to
someone starting their career as a software developer: irrespective of whether
your work is exciting or not as much, it is a joy in itself to keep working on
improving your craft, which is writing software systems. Excellence is always
a moving target, but if you stop working on your craft, the joy you will
experience as you become senior and older, will keep decreasing.

~~~
0x445442
This is my experience as well. At this point in my career, craft and quality
is about the only thing that keeps me from ejecting.

------
dev12778765
One more advice for young programmers is - make the effort and learn the
domain you are programming in. If you are writing finance software - use the
opportunity and learn finance/accounting. If you writing retail software,
learn about retail. If doing some network automation - learn about networking.
I neglected this early on and picked up only enough needed to complete my
programming tasks. Now regret this as could have ended up with more options
across industries I worked in. Even maybe start your own business if you
become expert in some domain.

------
randomsearch
Started coding in 1987. Have no idea what I’m doing. Regularly panic about how
little I must know. Can’t figure out if people giving advice and writing books
are genuinely a lot better than me, or just more confident.

~~~
rlonn
Haha, same here (but I started -81-82). Love programming but get my kicks out
of running code in production, not written code in a repo, so I'm always in a
hurry to ship and usually don't have time to learn the new, shiny tech and
practises. Which makes me feel out of date, ignorant, impostor:ish. But then I
realise (or tell myself?) that I'm shipping working functionality way faster
than most, and that I can't be so bad. I think.

------
Dowwie
The one point in this article that I will challenge relates to duplication of
logic. The moment you've come across two similar scenarios that on the surface
may benefit by a refactor and consolidation of logic, don't just instinctively
jump to it. Refactoring to a universal model can take a great deal of time and
effort. Days, if not weeks, may pass before your universal design is ready.
Consider the cost of time and effort. Others are waiting for this work to be
finished. Time is not on your side. Make sure you have a damn good business
justification for consolidating designs and fight your biases.

I am advocating for knowing the costs and benefits of your refactoring
decisions. If you can't predict what the costs are, take that as an indicator
that maybe you should avoid refactoring, just yet. Consider as a litmus test
discussing costs and benefits with people whom it will affect and try to reach
an agreement. If you dread the thought of having that discussion, you probably
ought to avoid refactoring. If you can't argue in favor of your refactoring
idea, it's not worth the effort.

Also, consider that just because you can re-use flexible designs doesn't mean
you will. You may not be the best person to consider the probability of re-
use. Assume that it's unlikely: YAGNI (you ain't gonna need it).

------
dchichkov
Started coding in 1988. What I've learned, it seems, that there are many
styles. That they are worth learning. They are part of the art we practice.
There are rules that these styles bring. And compromises.

Zen of Python. The exceptional beauty of John Carmack. Rebases of Google
Style. Dive into a Linux Kernel. Very Objective Apple Style. Infinite pains of
TensorFlow. Simple magic of SQL. Clarity of PyTorch. Unique ways of Prolog.
Formality of Antlr. Frictionless Microsoft Style. Completeness of Theano.
Abstract Syntax Notation One. Eldritch style of Michael Abrash.

~~~
specialist
Ditto methodologies.

Maybe analogous to mixed strategy equilibria from game theory.

------
wintorez
Regarding avoiding copy-paste; I'm a JavaScript developer, and from time to
time, I run `npx jsinspect src` in the root of my projects to detect copy-
paste. The results are always interesting.

~~~
picod
cool, if this is reliable enough to be part of CI process it will be super
useful

~~~
wintorez
Never ran into a problem with it myself but ¯\\_(ツ)_/¯

------
jmilloy
I'm at a point where I think that "(2) Code is a liability" is a fundamental
revelation that separates developers. It acts as a proxy for so many things,
including some from this post:

\- Code duplication should be avoided, but not if the alternative is
complicated or highly-coupled code. Duplicated code is increased liability,
and complicated code is increased liability. Sometimes two similar but
separate functions is just easier to read, use, test, and maintain; assessing
the "liability" helps you make the best decision.

\- Tests are good because they decrease liability of other code, but they are
themselves are a liability, so you can go too far (as many other commenters
note about TDD).

And "Code is a liability" is not a silver-bullet. It isn't specific or
prescriptive enough, and that's a good thing. It requires experience and
effort to understand what that means and to make use of it on a case by case
basis. But I think it does point you in the right direction by posing the
right questions and focusing on the important trade-offs.

~~~
house9-2
> Code duplication should be avoided, but not if the alternative is
> complicated or highly-coupled code.

100% agree.

Along these lines, avoid applying DRY principles to "incidental duplication";
You can end up coupling completely unrelated code if you are blinded by
removing all duplication.

~~~
Ma8ee
This is so important! You must have separate functions, even if they contain
the exact same code, if they are semantically different.

------
bungie4
The stack is to deep. Nothing is easy anymore. The technology count is
staggering. I'm close to retirement. I'm looking forward to pursuing my
personal programming interests while I work some mundane, no responsibility,
minimum wage job.

Programming is a ridiculous career path.

~~~
deanmoriarty
It is indeed ridiculous.

I am in my early 30s and I am aggressively saving as much as I can while
living very frugally, to hopefully retire multi-millionaire abroad or get a
lower paid job that won't stress the life out of me before I turn 40.
Hopefully I won't become unemployed before hitting my target, or die of a
stress-related heart attack.

I am not completely disappointed about my career choice because it allowed me
to save a lot of money (see note), but boy, it is an insanely ridiculous
career. Very frequently I wish I pursued something else, there is just way too
much and fresh new crap keeps coming, every week. Can you believe 4 years ago
almost nobody was talking about containers/Kubernetes? Just to name a random
niche. Can you imagine what will happen in a couple years? They say "it's all
the same, it's a cycle, you already learned it": that might be true if you are
a manager or a PM and you just need a very superficial overview of the
ecosystem, but if you are a senior engineer you need to master your craft, so
even if a technology has been reinvented you need to spend hundreds of hours
learning the details of this new incarnation, that's literally what your
employer expects. Ask an engineer if being proficient with VMWare is enough to
get up to speed with Kubernetes just because one is the sequel in the
virtualization scene... exactly.

Also add the effect of globalization: my company hires talent from Eastern
Europe (not consultants, entire teams with local management, product, ...) who
produce insanely high quality software products at a ridiculous pace,
exquisitely documented. Those people are wicked smart and on top of that work
20 hours a day. I am surprised software engineers are still hired in the US,
where working 10 hours a day is already considered unhealthy. I feel the same
way as a brick and mortar store that's going to get pushed out of business
because of the more efficient and cheaper Amazon.

Note: It also helps that I choose to live in the super expensive Bay Area
while not wanting kids, so I don't have the same spending requirements of
people with kids and can bank the spread that most people would have to spend
on schooling, nannies, good housing, ... I rent a studio for $2k in a ghetto-
ish area, and that's 70% of my expenses. If I had a couple kids for whom I
needed to provide good housing, nannies and private schools, I would be
spending all I earn and there wouldn't even be an end in sight to this
madness.

~~~
hstreet
I hope you can make it work. I am nowhere near the path to saving enough to
retire soon. Although I'm still holding onto the hope that I could build my
own path start enjoying programming again with the BS and pointless stress
removed.

To make that work though, I'm done with the interview circus. It's been such a
distraction over the past 3-4 years, that if I wasn't prepping for interviews
or staying up to date with the waste of knowledge that they test for in tech
interviews, I could've built a successful business already. Now I'm choosing
to focus my time there.

~~~
samtechie
These days the effort required to get a well-paying programming job is more or
less equivalent to the effort required to start your own business. If you can
start a business. It's worth a shot. Worst-case scenario, the business fails
and you are back on the job market but you can use your startup as a
demonstration of your capability to deliver on projects that require time and
dedication. You will also grow and learn a lot and be in a much better
position than your competition.

------
arduinomancer
When people say TDD does that imply writing unit tests before writing code?

Or do they just mean doing unit tests as you code?

I'm never sure when I hear this term because the benefits described (thing's
just working first try) seem to apply no matter what order do it in.

~~~
eikenberry
Pure TDD is, as the others have said, to write the tests first. If you aren't
writing code to fix a broken test you are doing it wrong.

TDD, though, is really a learning system. The main point is writing the code
with testability in mind. You can write them together and get the same results
as long as you do that. It keeps the code loosely coupled and the APIs clean.

So, IMO, you can still call it TDD as long as you are writing the code and
tests together and are writing the code with the tests in mind. You can do
that with the pure TDD or with some variant as long as the result is the same.
I guess it depends whether you are referring to the general style or the
specific learning methodology.

~~~
JMTQp8lwXL
Unless you're writing super functional stuff, I don't understand how you could
reasonably apply TDD when developing user interfaces: I target web, but the
same could hold for mobile and other devices.

Because, what exactly is the contract? Do I essentially write integration
tests to the effect of "If I click input element with css class .username,
type 'x', and then click input element with class .password, then type 'y',
then click the button with class .login, the page URL has changed from
<mysite.com>/login to <mysite.com>/profile?"

There are no clear API interfaces for UIs. A user wouldn't really care that
the button had class .username on it, for example -- that just gives us some
way to identify the correct DOM element to perform the e2e test against. And
some day, a developer could rename that class name, and it'd break the e2e
test.

In other words, I can't assumption what TDD looks like for user interfaces,
without the whole testing process seeming extremely brittle. Contrast this
with, if I call some REST API, I expect this response body. It's quite
concrete.

~~~
eikenberry
I don't think it is that much different, just maybe in proportions. In pretty
much every application I write there 2 types of code. There is the guts or
business logic that is written in the style of a library making it very
testable. The other is the top level code, the 'main loop'. This is just there
to hook together the library code in as short a way as possible. I think UI
code differs in that it tends to have quite a bit more of this top level code
that is basically un-testable except for very high level integration/scripted
tests and QA testing. But UI code still has some amount of the library/logic
code that can be written with testing in mine. I think this speaks to the myth
that 100% test coverage is desirable and good. It is not.

------
zvrba
Some of the things "I've learned in 25 years":

After arguing with a friend who claimed to have discovered a bug in `malloc`
because his program crashed (that was a long time ago), I figured that there's
a hierarchy of probable causes of bugs, from most probable:

1\. The code I wrote [you must understand only your code]

2\. A 3rd-party library/dependency [you must understand your dependencies]

4\. The compiler [you must understand the compiler-generated code]

5\. The OS, or OS-provided library [You must be intimately familiar with OS
internals]

6\. CPU, or other hardware-related [You must be intimately familiar with how
the CPU or other HW works]

It's basically arranged according to how many _other_ programs are using the
given facilities. Returning to the "buggy malloc", I did not dismiss his
theory outright just pointed out that if malloc _were_ bugged in such an
elementary fashion, that no _other_ programs could work, hence there was
overwhelming probability of _his_ code being bugged, not malloc.

\---

Just like security features, error-handling cannot be bolted on afterwards.
Robust programs begin with defining error-handling strategies and expected
outcomes in case of errors and building the rest on top.

\---

I could probably go on, but... meh.

~~~
GuB-42
The bug in malloc() is an old classic.

From my experience (about 20 years):

1- Obviously...

2- Some libraries are more reliable than others.

3- Missing, are you working for Valve?

4- I sometimes encountered compiler bugs, but it was things like compile-time
crashes, never bugs in the generated code.

5- Never happened to me. Or at least no bugs that weren't documented (there is
a BUGS section in manpages, read it).

6- Actually more common than the previous two. In fact extremely common in the
embedded software business. But even with PCs, bad RAM sticks and things like
that happen.

------
bbbobbb
Does anybody have some words of wisdom / articles / tutorials / books on TDD
for your typical web applications?

I am asking because for me, writing tests before the code is a natural choice
for pure functions where I can easily map inputs to outputs. I cannot imagine
writing that kind of code without tests.

But the usual task is gluing together tons of components and 3rd party calls
(e.g. starting from an HTTP request, doing some transformations, calling some
APIs maybe, persisting stuff in the database).

All of this depends on tons of side effects and hard to mock components. The
only test I can write there easily is a full contract that mapping the HTTP
request to HTTP response.

This doesn't help me with developing the internals (definitely not TDD), it
only verifies the end result.

Even worse if there is no clear response but the result is piped into some
queue over the network or something similar.

I am either completely incompetent or I develop applications that are tons of
hard to test stuff (especially with simple unit tests) with only tiny core of
functionality that seems easy to test.

~~~
dakom
Here's a few ideas on testing web apps:

1\. The internal pure data representation. If you're using some state
management like redux or xstate then you can just cache the state on changes
and run tests as-is (e.g. running the tests would be sending events and then
checking that the state is what you expect it to be).

2\. The page itself. Tools like Selenium and Cypress will allow you to easily
inspect and run tests against the DOM state (e.g. running the tests would be
emulating interactions with the page and checking that the properties of
elements are what you expect them to be)

3\. Checking the virtual dom (or other middleware). For example, with React,
you can "get at" its internal data (at least the level you need) via a testing
framework like Enzyme.

4\. If your app uses webgl context or is simply too hard to test on any of the
above "pure data" levels, you need some sort of image recognition to compare
pixels. I doubt this is going to be _perfectly_ testable but you can try your
hand at Sikuli or roll your own with OpenCV

------
algaeontoast
Do you / commenters here really “enjoy” programming as a career as much as
when they first had enough skill and enthusiasm to build things?

I think this is a big misconception among devs with less than five years of
exp.

~~~
faanghacker
I started programming when I was 11. Taught myself C++ from that age. Solved
tons of tough problems in personal and school projects before going into
industry at age 22.

Now at 35, I definitely think it's time to move on. I won't lie about my lack
of interest in the field. The problems are less difficult to solve, but also
much more frustrating. A lot more black boxes that you can't reverse engineer
when you get stuck. Working with other people in a big company means things
move far slower than my ability to get things done.

Plus the proliferation of different tech stacks means that despite the big job
market, most of the new jobs require specific knowledge that I don't have, and
my existing experience with low level coding and problem solving don't carry
much weight.

~~~
randomidiot666
> Plus the proliferation of different tech stacks means that despite the big
> job market, most of the new jobs require specific knowledge that I don't
> have, and my existing experience with low level coding and problem solving
> don't carry much weight.

None of those jobs _require_ specific knowledge upfront. The problem is
clueless fuckwits in HR filtering out CVs based on keywords. General problem
solving ability and knowledge of fundamentals means you can actually learn any
of the latest shitty frameworks in a few hours on the job.

------
neilwilson
I just wish I knew as much now as I thought I did 35 years ago.

------
Antoninus
I was very lucky that my first job out of school was at a Perl shop with
older, senior engineers. It felt like I hit the jackpot in mentorship. I
learned more with my two years with them than the next 5 where I cycled
through all the trendy frameworks and devops tools. I’m hoping to find another
small, experienced shop like that and where I can give my next 10 years;
willing to relocate and take a pay cut.

~~~
mettamage
How do you find those though?

~~~
Antoninus
As a new developer, I'd frequent a lot of meetups to build my network. I
always made a point to talk the oldest guys in the room as the conversation
was always the most interesting. I happen to be a sucker for dot-com bubble
war stories.

------
yahyaheee
From the creator of TDD on why TDD doesn’t work in many highly innovative
environments [https://softwareengineeringdaily.com/2019/08/28/facebook-
eng...](https://softwareengineeringdaily.com/2019/08/28/facebook-engineering-
process-with-kent-beck/)

------
CheesecakeFred
Point 2. "Code is a Liability" ends with the sentence: "Always strive to do
everything using as little code as humanly possible."

On its own I consider this bad advice.

I would change it to 'Always strive to make your code as easy to understand as
possible, while less lines of code and complexity is preferred'

------
teddyh
“From around the age of six, I had the habit of sketching from life. I became
an artist, and from fifty on began producing works that won some reputation,
but nothing I did before the age of seventy was worthy of attention. At
seventy-three, I began to grasp the structures of birds and beasts, insects
and fish, and of the way plants grow. If I go on trying, I will surely
understand them still better by the time I am eighty-six, so that by ninety I
will have penetrated to their essential nature. At one hundred, I may well
have a positively divine understanding of them, while at one hundred and
thirty, forty, or more I will have reached the stage where every dot and every
stroke I paint will be alive. May Heaven, that grants long life, give me the
chance to prove that this is no lie.”

— Hokusai

------
beagle3
The “no copy pasta” requirement leads to left-pad incidents.

------
Kiro
I've worked in multiple systems where we've needed country-specific DoX() and
you always end up completely separating them. You start trying to fit one core
logic for all countries but it always gets reduced into nothing and you wish
you had just copypasted the first country logic to the next to begin with.

Once everything is separated you feel much more comfortable introducing that
specific Mexico change without messing around with the core logic. Of course
things that are truly agnostic shouldn't be duplicated but that tends to be
extremely narrow in the end and you never know what it is before you have a
lot of countries. It quickly becomes a maintenance nightmare trying to fit
broad logic to impossible flexibility.

------
bsaul
Things i’ve learned after 20 years :

\- understand and care about context. Understand the input and output of what
you’re developing. Why people need it to function a certain way. And how
people are actually going to use it.

\- business trumps tech (most of the time). Not just in matter of how well a
company will perform financially, but also in everyday developer life. For
example : a different business model may imply a different tech stack choice
(and that’s just one example). Understand and care about the business side of
the place you’re working in. It’ll also helps you greatly communicating with
your managers.

------
z3t4
What relates to me is when he was gonna write how awful TDD is, then he
actually tried it - and liked it! There are so many things we think are
utterly stupid, but have never even tried.

------
patrec
Is there a single example of a notable great programmer who uses TDD?

~~~
cateye
Martin Fowler is an example.

~~~
patrec
What makes you think so? Have you seen any great code he has produced or are
you aware of him having implemented something decidedly non-trivial? I might
be wrong, but my impression is that he's someone who spends almost all his
time telling people how to write software, not writing it.

------
mcovey
First one was an immediate turn-off. Duplicating code once is fine. With the
given example, there's no need to start building an abstract billing method
and a data structure to encapsulate the differences in billing between
different countries, because there are only two countries and one is new. Wait
for a pattern to emerge before refactoring, especially when such refactoring
will make the code more complex and harder to reason about.

------
TravelAndFood
"Do you know what correlates more than anything else with undesirable codebase
properties? The size of the codebase."

Well yeah, more code means more bad code. I'm interested to know whether more
code means _proportionally more_ bad code. If not, his statement doesn't mean
much.

------
apatheticonion
What about copy/pasting interfaces between packages to avoid cross package
dependencies

------
solidist
[https://twitter.com/dougarcuri/status/1198217546362753025](https://twitter.com/dougarcuri/status/1198217546362753025)

------
kamaal
1\. Interview skills >>>>>> Job skills, productivity, and ability to get work
done.

2\. Learn office politics and learn to do it well.

3\. Everything else is irrelevant.

------
rsmckinney
10 years of coding in trade for 10 years of middle management... why would I
follow your coding advice? A serious question.

------
RhysU
There's some silly Moore's law variant buried here: The programmer demand will
double every couple of years.

------
bitpow
> Learn yourself some TDD. You won’t regret it.

How?

~~~
cjfd
Read the book. Worked for me.

~~~
cjfd
And after you read the book do a simple toy project to try it out.

------
turk73
Going on about 17 years here.

It's not looking great for the future in terms of staying a developer. It's
getting harder to find reasonable jobs anymore. My current one and the last
one are/were disappointments.

I think the best words of advice are: Devise a career backup plan. I don't
currently have one even though I have exerted effort in that direction.
Probably end up a stocker at Home Depot or something. Hope not.

At some point, knowing another language or framework may be interesting to
you, but it is pretty much immaterial unless you are going to use it on that
job. For instance, I love Kotlin, but there's no Kotlin developer roles in my
market hardly. Waste of time. Same thing happened with Clojure. I never learn.

You will be too expensive: I recently went after a Kafka Architect role which
I should have been a slam dunk for but when it got to price the other side
suddenly got all wobbly, excuses appeared, and poof, it disappeared.

Companies want cheap, throw away talent. I will say it again: Companies want
cheap, throw away talent.

~~~
theonething
Would you comment on what made your current and last jobs disappointments?

I don't even know what the baseline is for satisfying programming jobs. All my
jobs have been similar in terms of points of frustration.[0] I've just kind of
accepted it as normal.

[0] I would elaborate but don't have time right now. At work.

~~~
cr0sh
> I don't even know what the baseline is for satisfying programming jobs.

For myself, it's always been about the team I was a part of. When you are part
of a team that takes pride in their work, and they perform well together,
supporting each other, learning from each other, etc - no "prima donnas", and
they all have fun doing it - it leads to a good day of work.

I'm lucky in that for most places I have worked - from the first shop that
took me in, to my current employer - this has been the case. I can only think
of a couple of places I worked where that wasn't entirely the case; both came
with excess politics, and other stress that I just didn't (and still don't)
understand. I stuck out with it at both, but I'm glad I'm no longer a part of
either.

One thing I do know and understand - this comes from someone who started their
software engineering career when they were 18 years old, and now I'm pushing
50 - every place I have worked that I have had this "good team quality" has
been a small employer, usually with fewer than 50 employees. My current
position, there are fewer than 20 employees.

No - I don't make, have never made, and likely never will make "FAANG" money -
but I'm not stressed either, and I make enough to keep a roof over my family's
head, the lights on, and food in the pantry. I'm content, and if an
opportunity comes up for a FAANG-money type position - I will have to look
long and hard at it, before making that leap - because I feel that it might
come with costs that just don't make sense to me any longer. I'd rather have a
more "basic" salary and little stress, than a lot of money but stress out the
door due to a myriad of reasons in such a workplace. That isn't to say that's
inevitable, but I've just found that as the employers I've worked for were
larger, the less my satisfaction with going in and the job overall.

~~~
away_throw
I'm just entering the field (19-yo), and I don't have an particular experience
in the field yet. From people I've talked to, jobs that you describe are the
best options. I'm particularly interested in government jobs for these
reasons.

~~~
wolco
At 19 work everywhere. Startups can offer so much value at your stage with
freedom if you choose right.

