
On becoming a better developer (2015) - kristianp
https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
======
edanm
You have to decide what exactly it means to be a better developer, and what
exactly _you_ specifically want to achieve.

I personally made the choice, a few years ago, to focus a lot less on being a
"great developer" in terms of writing the best code, and focus almost solely
on "what can I actually achieve with code I write". That's why I refocused on
learning new _domains_ rather than deepen my knowledge about programming, e.g.
learning ML and Data Science, instead of learning new languages or getting
better at software design principles.

The end result is that, while I might never achieve _mastery_ of software
architecture or of Python or other more software development oriented things,
I can effectively do new things that I had no idea how to do before.

Another example - let's say you know just Python. In choosing between learning
Haskell or learning 3d programming, learning Haskell will definitely deepen
your knowledge of programming, of languages, of functional programming. But,
end result, you won't be able to make something qualitatively different that
you couldn't make using Python. Learning 3d _will_ allow you to make new
things.

Note: I'm _not_ saying one thing is better than the other. Different people
care about different things. I'll also point out that I've been a developer
for 20 years, so I hopefully achieved a pretty high level of knowledge in many
purely software development ideas before branching off to learn whole new
domains. :)

~~~
alpos
>In choosing between learning Haskell or learning 3d programming...

This is a false dichotomy:
[https://wiki.haskell.org/Game_Development](https://wiki.haskell.org/Game_Development)

As the linked response from Rich Hickey pointed out, you can do anything in
any (Turing complete) language.

I agree with the notion behind your decision to focus on real results though.
I think that is actually closer to the mastery part of the progression from
beginner to master. I think when one can deeply realize that programming is
just a tool to achieve other things, then one is leaning towards the mastery
end of the scale.

That's not a hard rule though, I think part of the problem we all have
discussing this sort of thing is that we have a hard time consistently
measuring where a person is on that progression.

~~~
theodorton
> you can do anything in any (Turing complete) language.

Exactly. The point of the parent was what to choose between learning a new
domain or a new programming language (when you already know python) and what
would give most value combined. I agree that knowing python+3d will be more
valueable than python+haskell.

------
bsaul
"Musicians get better by practice and tackling harder and harder pieces, not
by switching instruments or genres, nor by learning more and varied easy
pieces"

You do however becomes a better musician by playing different instruments,
even if you're only really good with one. Learning drums as a piano players
helps you focus on rythm precision.

I'd take a general developper that knows both mobile and backend over any
specialized mobile developer anytime.

~~~
icc97
Someone who's bilingual can have meaningful conversations in both languages.
Beyond that they can see the connections/differences between the two languages
and gain a deeper understanding.

However someone who's learnt 15 can probably only order a coffee in each one.

~~~
carlmr
>However someone who's learnt 15 can probably only order a coffee in each one.

Talk to Ioannis Ikonomou who's considered to be good at 32 languages and has
cursory knowledge of a few more:
[https://en.wikipedia.org/wiki/Ioannis_Ikonomou](https://en.wikipedia.org/wiki/Ioannis_Ikonomou)

He's even a certified Chinese translator, and that was one of the later
languages he learned.

I think you'll be surprised if you go to Europe how many people you'll find
who can do a bit more than order coffee in at least 5 languages.

~~~
icc97
I did say 'probably'. If someone can speak more than 12 languages they're a
hyperpolyglot. You'll probably find as many living Nobel Prize winners as
hyperpolyglots.

Plus I live in Belgium and my partner speaks 5 languages.

I think the comment still stands for most mere mortals.

~~~
carlmr
Yeah, I agree, most people can't speak 15. But more than bilingual is very
common at a somewhat good level.

------
twblalock
In my career, the biggest factor in my growth as a developer has been working
with better developers. To work closely with someone who is really good at
what they do is the best education you can get.

~~~
wool_gather
This is a frustration I have with my current position. I'm the second most
experienced person on the team, and most knowledgeable about our platform. And
I'm...not that experienced or knowledgeable. Big fish, small pond has never
appealed to me. It gives me no one to check my ideas with, and pulls me, as
much as I consciously resist, down the path to being a know-it-all Dunning-
Kreuger assbutt.

~~~
0x445442
Yeah, in general, if you determine you're the best player in the band and have
been so for a while then it might be time to consider changing bands.

------
hyperpallium
Abraham Lincoln studied Euclid to become a better lawyer (to learn how to
"demonstrate").

I've just studied a tiny bit of Euclid, and his design of lemmas (technical
theorems, not beautiful in themselves, whose beauty is neatly meeting needs in
higher-level theorems), is program decomposition into modules, _that you can
see_.

I can't be sure yet, but I feel I'm already thinking more clearly.

EDIT _Euclid_ means "renowned," from eu "well" \+ kleos "fame".

This jibes well with the team-theory: _" Because the lack of biographical
information is unusual for the period (extensive biographies are available for
most significant Greek mathematicians for several centuries before and after
Euclid), some researchers have proposed that Euclid was not, in fact, a
historical character and that his works were written by a team of
mathematicians who took the name Euclid from the historical character Euclid
of Megara (compare Bourbaki)."_
[https://wikipedia.org/wiki/Euclid#Life](https://wikipedia.org/wiki/Euclid#Life)

~~~
n4r9
I had the same insight from the opposite direction. My background is
mathematics but have been struck by the similarities between refactoring code
and splitting a proof into lemmas, corollaries and theorems. There's also an
art to creating good definitions during mathematical exposition, which is akin
to creating variables to encapsulate the right data and naming them well.

BTW Pythagoras is another ancient Greek who may well not have been a
historical character.

~~~
hyperpallium
Please bear with me while I draw a parallel:

 _Elements I, 32_ (triangle sum theorem)
[https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.htm...](https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.html)
looks lopsided - especially compared with this nicely symmetrical one:
[https://math.stackexchange.com/q/2727737](https://math.stackexchange.com/q/2727737)

But _I, 32_ also shows that an exterior angle is the sum of the two opposite
interior angles - which seems an odd, weird thing to prove, but fits nicely
into other theorems. The one I've seen is the proof of the inscribed angle
theorem, _III, 20_
([https://mathcs.clarku.edu/~djoyce/elements/bookIII/propIII20...](https://mathcs.clarku.edu/~djoyce/elements/bookIII/propIII20.html)).
The diagram has much going on, but the relevant parahraph is labelled with a
link to _I,32_ on the right.

The parallel with code is that I've sometimes seen very clever methods, that
extract an odd-shaped piece of code, from several places. An example is from
maths, the delta-mew algebra (forgotten the proper name) for numerical
differentiation in computational fluid dynamics. Though, that example is
really maths again.

The thing I wonder is if this is _too clever_... if a module has intrinsic
beauty/sense/symmetry, it's easier to understand, remember and use -
especially for the next neophyte to touch the code (or me in six months).
However, maybe if you are an expert (like Euclid), these helper-theorems
quickly became as familiar as alternate interior angles have for me...?

I think the difference is geometry is always the same, one eternal codebase.
The modules can be reused all the time. But programmers are writing new code,
in new areas (to them), all the time. So perhaps we just can't get to that
level of specific mastery (of particular methods) - if we did, we should fully
encapsulate them somehow! We need APIs that let us ignore the details - unless
you work in the same area, long term (perhaps in writing an API).

Of course, just like modules, we can use a theorem and ignore the details
(proofs)... but in the above case, we still have this odd, asymmetrical
_shape_ in the theorem, which is (I think) similarly hard to understand,
remember and use. Even though that shape is a more useful one!

What do you think?

~~~
n4r9
I'm finding it difficult to pinpoint where/why you think there's a difference.
Absolutely there's a strong parallel between an oddly constructed theorem and
an odd-shaped piece of reusable code.

Geometry may be an eternal, perfect realm of ideas, but the actual _codebase_
is the book, which is exceedingly good but is not perfect, especially given
the restraints of the medium (written text).

Someone who is practiced or naturally talented will be able to read that book
with a similar ease with which you read elegantly written code (c.f. Einstein
being amazed at the "lucidity" of Euclid's elements at the age of 12). For
everyone else, I can imagine having a different, easier to grasp codebase for
Euclid's elements: perhaps transcribe it into a wiki-like computer document
which allows the reader to browse and flick between the referenced lemmas much
more easily.

Both mathematical exposition and coding, and in fact almost any sort of
writing, involve a sort of data compilation from a very high-level language
("how I/we understand it in my/our head/s") to a lower-level language which is
more rigorous but lacks an interactive element.

~~~
hyperpallium
Well, I'm still struggling with the question!

I wasn't thinking ideas _vs_ their expression.

I see you're saying: you can have different expressions of Euclid for people
of different abilities. (Actually, even different proofs for different levels:
the high school proof of the Inscribed Angle Theorem is different in part from
Euclid's, _III, 20_ (though I found Euclid's clearer and simpler)).

The difference I noted was just that geometry is like _one_ codebase. But
programmers deal with many codebases - there's no ugrad or high school course
in a particular codebase!

Though, in a large company, do you get experts in their key codebase, both
practiced and talented. But there's still a reluctance to invest your all in a
codebase - what if they rewrite? Or go out of business? Or you quit? Your
investment is lost. Not so with geometry.

There's also market forces for the adoption of third-party libraries (a
library of theorems - like Elements' books!) - dominating the market will
require being accessible to a range of abilities. A "pop culture", for better
or worse.

I guess you'd say: "fine, the easier expressions will dominate". But I don't
think there'll be any higher expression at all...

So... not a difference in essence, just in its role in the world.

BTW I find Euclid very hard to read, but easy to understand (so far, anyway).

BTW those links I gave are to a "wiki-like computer document".

------
Daycrawler
This really isn't understandable without the context of the article this one
is a rebuttal of ([http://jasonrudolph.com/blog/2011/08/09/programming-
achievem...](http://jasonrudolph.com/blog/2011/08/09/programming-achievements-
how-to-level-up-as-a-developer/#comment-287120251)), and specifically this
"method" that the author of the first article uses the be a good developer:

    
    
        1. Identify the experiences that advance a person as a developer.
        2. Select a particular experience to pursue.
        3. Pursue that experience to completion. (Achievement unlocked!)
        4. Reflect on that experience. Really soak it in.
        5. Return to Step 2, this time selecting a new experience.
    

The rebutal's point is that instead of cycling back to step 2 after step 5,
you should continue above and beyond, becoming really expert in the field you
decided to pursue.

What the rebutal misses, in my opinion, is that in order to go beyond step 5,
you need to have chosen an ambitious subject in a first place. A symptom of
wanting to cycle from 5 to 2 is that the experience you chose isn't that
significant and you can explore most of it quite rapidly. I see it a lot in
the web development world, where after having done one or two CRUD
applications devs have seen it all, and start cycling through technologies,
frameworks and methodologies to make it more spicy.

One solution to this is to move deeper into the backend of rich and complex
software/websites, where solving problems related to distributed systems,
algorithmic efficiency and architecture will provide (but also require in a
first place) vast knowledge and experience; enough for one career at least.
Other fields than webdev also work well for this, including embedded systems,
security and digital imaging.

------
greenhatman
I look at this in the same way that I used to look at creating Diablo 2
characters when I was a kid.

You're building a skill tree. The first thing you need to take into
consideration is whether you're playing with other people or solo.

If you're playing solo, you need to be more of a generalist. You need to pick
just the right skills so that you're able to handle an scenario that the game
will throw at you. You need to be able to deal at least two types of damages,
for when you're facing monsters that are immune to some types of damage. You
also need decent defence. And preferably a way of travelling over obstacles.

When you're playing with other players, you can go for only one type of
damage, and pick other skills that amplifies or synergises with this skill.
You actually don't have to focus on damage much, if you can tank and take
damage well to protect other fragile players who do lots of damage. Or if you
focus on doing lots of damage but you're a bit of a glass canon, you just need
to make sure that you're playing with another player than can pull the
attention of dangerous monsters.

In both scenarios you need to pay attention to how you build your skill tree.
Just the considerations are a bit different.

I tend to pick skills and technologies to learn that are on different parts of
the stack, because I often work alone or in small teams. I need to be able to
create a whole app with front-end and back-end and manage the infrastructure.
So I only pick one front-end framework, one back-end framework, and one or two
infrastructure tools.

It's a tall order, but you can do it if you don't spend time learning things
you don't need to.

On the other hand, people who work in large teams are usually better off
focusing on their niches. So if you're a front-end dev, you can learn 2 or 3
different front-end frameworks, and it will make you a more effective front-
end developer in both. It's just that you get diminishing returns with each
new front-end technology that you learn. But this is work it if you're in a
position where the other parts of the stack are handled by people who focus
all their efforts to be exceptionally competent there.

~~~
jcadam
I consider myself a generalist. At least, on my side-projects, I'm a
generalist because I have to build the entire "system" all by myself :)

At my day job, however, I'm specialized more into backend stuff: architecture,
databases, etc., it pays decently well, but it's become so familiar (and
mostly straightforward with the types of problems I work on) that it's
starting to get boring.

My 'other' skills which I've cultivated on my own time do occasionally come in
handy at the day job, however. I do try to hide the fact that I know how to do
things like system administration, ansible, etc. ;)

------
dwaltrip
Two metrics for developer greatness:

1) How complex are the real-world problems that you are able to solve
effectively?

2) How robust and long-lasting are your solutions?

Note that these metrics are actually not specific to software at all!

\---

The post essentially says the same thing near the end, with the distillation:
"the ability to acquire knowledge, and the ability to solve problems".

Interestingly, you could view this as actually only looking at a single
variable, but considering both its current value (problem-solving ability) and
the change over time (ability to acquire new knowledge).

------
mnm1
I agree completely. Programming is not some special skill that deviates from
the norm. It helps a lot to master one language before moving on to another.
This is not to say that trying new languages is not a good idea, just that the
focus should be deep not shallow. Unfortunately, a lot of this industry is all
about shallowness when it comes to hiring. It's almost like having experience
is looked down upon, but knowing the framework of the day is a critical
criteria for hiring. I think part of this is because the industry is dominated
by incredibly short lived, incredibly buggy, incredibly low quality software:
aka what every startup anywhere develops when it sees itself not as a
sustainable business, but one with an exit a couple of years down the road.

------
TheCapeGreek
While this does make sense, as a junior developer what I'm trying to grapple
with is how fast our tools (specifically the "standard" languages) change. I
can become a master in Laravel and PHP after years of work, but by the time
I'm at that point the world will have moved on. My capabilities within my
skillset will be impressive yes, but will it help me in the new industry
environment?

I think it's that fast-paced nature (and partially scaring newer devs into
trying to keep up) that causes many of us to try and learn broadly rather than
deeply. For an analogy, it's like investing in an index fund and being
diversified (and thus having more overall potential for gains and less risk of
loss) than a single stock.

Disclaimer: I'm still fairly new to the industry for all intents and purposes
so I welcome opinions on this.

~~~
lghh
The best way to circumvent this feeling is to learn how programming works
rather than how PHP and Laravel work. If you know what a web server is, how to
scale it, know a little about web security, and how to write OOP well you're
in very good shape. Don't learn the intricacies of Laravel, you can pick those
up on the job. Learn enough about PHP to be able to identify what goes into a
programming language and to be able to look at other languages and tell how
they are different and the same past one using the word "const" instead of
"let".

~~~
jxub
Or become an ES6 ninja and use both "const" and "let";). On a more serious
note, it's strange how has "let" became an identifier for mutable data in js,
while eg. ML uses it for the opposite if I recall properly.

~~~
chillee
Well, ML doesn't explicitly use it for immutable data. It's just how you
declare variables. It does happen that most variables are immutable though.

------
JimRoepcke
The first sentence is "Sorry, I have to disagree with the entire premise
here."

What entire premise? What is this in response to?

~~~
kens
I too was puzzled about what this is in response to. Midway through the
comments I found a link to the premise article:
[http://jasonrudolph.com/blog/2011/08/09/programming-
achievem...](http://jasonrudolph.com/blog/2011/08/09/programming-achievements-
how-to-level-up-as-a-developer/#comment-287120251)

It's responding to an article saying the way to improve as a developer is to
have more "experiences". To summarize briefly, some examples from the article
are to write an application in a bunch of different programming paradigms.
Write an app in a bunch of different platforms. Write a bunch of different
types of programs. Do a bunch of different open source things. Do a bunch of
different conference/teaching things.

Personally, I think a laundry list of "experiences" kind of misses the point.
If I think of great developers, they don't really check off many boxes on that
list. Their ability is basically orthogonal.

~~~
BrissyCoder
Thanks man.

~~~
edanm
Just FYI since you appear to be a new user: on Hacker News, writing comments
like yours is considered bad form. You should instead just upvote the parent
comment, that's the HN way of showing appreciation.

The reason is that, at least in theory, every comment on HN should be adding
value for people to read, and reading a bunch of "thanks" messages is just a
waste of time. Much better to just have the original comment appearing higher
because it got more votes.

~~~
0xBA5ED
Just say you're welcome.

~~~
edanm
I'm not sure I understand?

It wasn't my article, I'm just pointing out the site policy to someone who
appears new so that they don't get downvoted in the future.

~~~
0xBA5ED
My apologies. At the time, I was expressing my distaste for what I view as an
over-zealously regarded sentiment here, but I did mistake you for the above
user :)

------
joelcornett
Personally, (I can’t speak for everyone, or even most), I find enormous value
in breadth of knowledge. For example, purposefully using different programming
languages and/or different paradigms actually gives me a deeper understanding
of the core problems that lie at the intersection of all of the various
approaches and implementations of things.

Software engineers are first and foremost builders. We take components of
varying degrees of abstractness and arrange them together in scalable, fault-
tolerant ways that are amenable to change.

It is the understanding of the underlying and often transcendent principles of
building things that I am a lifelong student of. To borrow the music analogy
referenced in the article: you don’t get good at playing the piano by playing
the same pieces over and over again. You become a great pianist by
understanding and internalizing the relationship between rhythm, scale, then
motion of the keys, and the reaction of the listener. You can only do that by
playing (and listening to) a wide variety of music.

------
laktek
One important thing that was ignored in argument was you need to be nurtured
in right environment to achieve mastery. Some people have that privilege
(being born in right city, admission to a good school and landing a great
first job).

Personally, doing stuff original author suggests like contributing to open
source software and giving conference talks helped me to get noticed and
picked into places that gave me the opportunity to grow.

What’s important is doing those steps strategically to reach your goals.

------
Philipp__
Basically by reading comments here, every single person has it's own view.
Maybe there are too many variables in the equation to have bigger consensus.

Clearly it's a trade-off situation; I am on my early beginnings of journey to
mastery, but what I decided and how I tackled the road was going for T shape!
I am sure many know of this, where you cover all areas broadly, knowing what
they are about and you've done some work with them at some point and time, but
you didn't dig deep. Except one specific thing, that is your jam, where you
chose to specialize and dedicate to go deeper. So in the end you are forming T
shaped profile. I am near the end of studies and near the end of phase of
trying everything. I know what kind of language/technology/tools, kinds of
programming etc etc I like or dislike, so I think soon enough I'll be ready to
chose that _one_ thing. Of course it doesn't mean you are done for life with
other things, you have to catch the loop and ever changing nature of our
industry.

In the end, why advices and stories on this topic vary so much is because we
as humans are very different between each other. We react with different
sensibility on different things in different times & places. So by the nature
of things everyone has it's own journey to tell. But the problem occurs when
people take it to personal and start pushing it over other people's attitudes
and thoughts.

------
lmilcin
I think is _some_ amount of specialization (which makes you generally good in
your chosen area of expertise) balanced with _some_ amount of broad
experience, which puts the "icing on the cake" and lets you discover
connections that other people in your organization could not.

I am mostly working as a Java developer for large and very large corporate
backends. I also have following experiences:

\- sysadmin for critical applications,

\- embedded development for payment terminals with severely restricted
resources but lots of requirements

\- algorithmic trading (guaranteed single-digit microseconds
request->response)

\- infrastructure automation (Infrastructure as Code, etc.)

\- Linux kernel and general Linux platform development

\- high level (automated reasoning, optimizations)

\- embedded with control theory

\- cryptographic protocol design

All this I think makes me much better Java backend developer that I could ever
be if I just spent all that time on Java backends alone.

I frequently make various connections, am able to build much more efficient
and reliable applications that I could without that added experience. I have
much more balanced (you could say, mature) response to new technology,
language features, frameworks, etc. -- in no small part thanks to Common Lisp,
at the cost of no longer being content with Java. Or C++. Or any other fancy
language that is not Lisp.

------
Noumenon72
Reminds me of how "confusing the muscle" came and went out of style as people
realized you need specificity of training and you need to train a muscle with
the same motion during its supercompensation recovery phase for it to further
grow.

~~~
mlevental
what is the supercomprensation recovery phase?

~~~
Tuna-Fish
[https://en.wikipedia.org/wiki/Supercompensation](https://en.wikipedia.org/wiki/Supercompensation)

As a gross oversimplification: when you train a muscle hard, it accumulates
low-level damage. This is why if you train continuously without any recovery,
your ability level goes down, not up. The recovery phase is when your body
repairs all that accumulated damage and builds the muscle back. Only, it
doesn't stop at the level you started at, it goes past that and makes it a
little stronger than it was. This is the supercompensation phase. If you just
let it be, performance will eventually return to where you started at. But if
you train again during this phase, you can reset the cycle, starting from a
higher point.

------
carlsborg
Misses out some big ones:

* Knowing how to disagree. * Knowing when "being helpful" is more important than "being right" and when the situation demands it. * Empathising with your end-users and developers who will one day own your code. * Managing a schedule and communicating it.

------
blauditore
> Musicians get better by practice and tackling harder and harder pieces, not
> by switching instruments or genres, nor by learning more and varied easy
> pieces.

I wouldn't agree with this statement in the first place. Switching instrument
or style gives you a different perspective on music, and the same applies to
software engineering.

If we want to go on with metaphors, 100 m dash runners don't only repeatedly
run 100 m again and again during trainings. They do long runs, interval
traings, weight lifting and much more.

Of course, diving deeper is necessary if you want to become expert in a field,
but this doesn't mean excursions are not helpful too.

------
cocktailpeanuts
I respect Rich Hickey, but let me be a bit of a contrarian here. Feel free to
hate on me:

First, try replacing "developer" with a "production line worker" from the
article and see how that feels, because that's what I feel "development" is
turning into.

One of the most respected qualities of a programmer used to be "creativity".
This is not the case anymore. Nowadays developers are so focused on "being
seen as a good developer" than actually thinking about why they are a
developer in the first place--to build cool stuff that can have huge impact.
It's understandable since "being seen as a good developer" is what makes you
money.

The concept of "developer" is turning into nothing more than a production line
worker. If you don't believe me, just sit back and try to think of what tools
you're using to build apps.

Is it YOU who's using the tools? Or is it the tools that are controlling you?
You see this in all the "cutting edge tools" you must learn if you want to
call yourself a good developer, such as webpack, react, grunt, gulp, npm,
mocha, gradle, etc. etc. You spend most of your time learning these meta-
technologies than actually building stuff.

These are great tools, but what they're also doing is automating everything so
there's less room for creativity. Everybody builds apps the same way. Note
that I'm not saying this is bad. I'm saying the "developers" are unknowingly
becoming just a cog in the machine which can be replaced easily.

And I'm sure it WILL be replaceable because we are increasingly surrounding
ourselves with these uniform ways of doing things. In the end there will be no
room left for so called developers.

And when that day comes, it won't be the "better developer" who will be worth
a lot because all these techniques you learned will be replaceable with
machines. You may think that's some paranoid sci-fi stuff and you're still
making $120K a year so you're just fine, but wait till you find yourself
looking like a production line worker who get let go because machines are
better at doing what you do. Let's be honest, most programming nowadays is
nothing more than plumbing together multiple modules written by other people.
These abilities won't be valuable in the future because they are totally
replaceable with machines.

What truly matters is your ability to ideate and build something novel. Don't
just follow the herd and do what the famous people say or tweet online,
because you will end up becoming the casualty.

I guess what I really wanted to say was "don't try to become a better
developer, try to become a better creator", because otherwise you'll be easily
replaced in the future. It's coming.

~~~
AlotOfReading
Turning developers into production line workers is precisely what needs to
happen. The way we produce code is so ruinously expensive that nearly everyone
in this industry accepts the tradeoff between developer velocity and product
quality. The only way out of this is to automate programming so thoroughly
that only the creative necessities remain.

~~~
alexashka
Expensive in comparison to what exactly?

The only other science that's cheaper is math. Now I know plenty of human
endeavours that bring absolutely nothing of value, and only serve to
concentrate wealth, and cost everyone worldwide billions of dollars.

Are you aware of the military budget of the greatest country on Earth?

Ruinously expensive - what an apt description, just not for computer science.

~~~
AlotOfReading
In comparison to virtually any other design work. The most expensive
commercial buildings ever constructed are in the neighborhood of 5-15 billion
USD. Developing a Linux distribution from scratch would probably exceed $10
billion in developer costs [1]. Just think about that. Linux, not even the
largest codebase known, compares with the most expensive civil engineering
projects in history.

Code is phenomenally expensive.

[1] [https://www.linux.com/publications/estimating-total-cost-
lin...](https://www.linux.com/publications/estimating-total-cost-linux-
distribution)

~~~
icebraining
That sounds extraordinarily cheap, actually. The most visited mall in the
world has something like 80M visitors/year. Linux has literally billions of
daily users, and it powers everything from their phone to the public transport
network they use.

------
forkLding
I dont know, I seem to learn a lot more from different programming languages,
frameworks and libraries.

I could get deep knowledge in Java but wouldn't learn how to deal with
concurrency from functional programming until maybe Java Lambdas and thus use
some kind of object oriented hacking with locks, or a myriad of other useful
methods and thinking that would be either much harder or un-doable in Java
that has added to how I deal with code.

On the other hand, that could be the mark of a beginner so I might be
mistaken.

~~~
jkoudys
I've frequently found that when I go back to code I've written long ago, the
new languages/libraries/patterns I've learned about since could have helped me
back then.

I used to be terrible at templating (presentation) many years ago. Like a lot
of people I took it for granted, and considered it an afterthought compared to
more "serious" work like writing backend business logic or data modelling.
After hitting some frustrations writing a frontend, I started learning all I
could to avoid writing those same giant html-templates rife with
microlanguage, inline for loops, hugely nested conditionals, etc. I started
reading up on xslt and a lot of the reasoning behind it. While anything XML is
torturous to work with for a variety of reasons, a lot of the lessons I
learned about writing good xslt (e.g. defining larger templates as composed of
smaller ones, preferring `apply-templates` to 'map' datasets over explicitly
for-looping over them) transferred to any other language. Eventually this got
my interested in facebook's hacklang and its XHP syntax, which led me directly
to React (jsx felt like XML that didn't scold me every time I forgot to spend
300 characters writing namespaces at the top) once it came out, and I was one
of the first adopters.

Nowadays, I feel like I could probably go back to es3 and use plain functions,
concatenation, and array methods and write better templates than I could using
any fancy lib before, since I actually understand what I'm doing.

~~~
forkLding
I can see what you mean, going to stop arguing on the internet anymore,
realize its both addicting and embarrassing, any way to delete comments?

------
stonemetal
Note: the article is from 2015.

To get better developers need to increase their area (Breadth * Depth). Going
deeper and deeper in one area may make you an expert on that topic, but it is
easy to become irrelevant if you have no breadth and a disruption occurs. Of
course being wide but shallow can be equally troubling, since you can't do
anything that requires more than the basics.

~~~
nnq
It's more like going "breadth first, depth later" vs "depth first, breadth
later". RH argues for the second.

I 100% with OP since if you start "breadth first" you can just exhaust
yourself before you've made any significant progress on the depth dimension
(because there's so much variety in technologies, a lifetime is not enough to
learn them all, and one you try to "spread out" you never know when to stop").
Also, going "depth first", you get clear feedback about when you've went deep
enough and need to branch out a bit: things just start feeling _too_ hard!

Otherwise you can end up "repeating your first year for a decade" and end up
with a much smaller total area.

------
icc97
I think there's a quote from Paul Graham somewhere along the lines of 'T-Type
learners':

> Like paint drops rolling down from a paint stroke, the breadth is there but
> at certain points the paint rolls down creating deep lines

So you can skim the surface but at some points you have have real focus. You
need to choose these carefully and dive deep into them.

~~~
AstralStorm
You can also go the other way around. It'd may require unlearning habits and
be harder that way.

I think getting at least some depth when starting is necessary. Otherwise your
skill is not usable.

------
BrissyCoder
What is this in response to? What/whose "entire premise" is he disagreeing
with?

------
dale14
Couldn't agree more

