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. :)

There ought to be, if there isn't already, a phase in most peoples' journey with programming where they dig into and experience the fundamentals; the maths, structures, and practical application of theoretical techniques. The reason being that you're not going to get very far in any domain if you don't know how to deal with complexity.

I think there comes a turning point when you've mastered enough of the fundamentals that domain knowledge becomes more useful. Code becomes an artifact of solving problems in your domain. If you've mastered the fundamentals the correct code (for some appropriate definition of correct) becomes easier to develop. Regardless you end up becoming more of a domain specialist and programming is just your _force amplifier_.

Though I think this can get a little dangerous with some folks who might mistake our ability to "learn as you go," as some innate ability to understand and solve problems in any domain. I think this has an effect on our industry where programmers with little experience in a domain think they can write software to solve problems in that domain and iterate until they learn that domain and voila! Disruption!

The problem with that is there are some domains that require mastery due to ethical and legal constraints. There's a reason why you don't just become a civil engineer by following some blog posts and watching Youtube videos.

Still I think that if you are going to be a civil engineer -- if you know a thing or two about programming, like knowing maths, you will be a "10x civil engineer."

I don't think that will change much until the overwhelming demand for more software is mostly met with a sufficient number of properly trained Software Engineers. At that point we should start seeing real competition on the quality of the solutions. (and a move towards professional licensing)

It seems likely that the first civil engineers saw a similar pattern. When you have a creek to cross and no one around is qualified to design a bridge, someone gives it a shot anyway. If it collapses they try to build a better one (iterate). Hopefully this can be accomplished without killing anyone.

Now that the world has a decent number of properly trained Civil Engineers though, we don't need to wing it most of the time; especially for the big, consequential projects.

Why I still think we're in a dangerous area with this is that there are established industries with domain experts who simply are not programmers. Inexperienced programmers might come in with solutions to problems that have genuinely good intentions -- a bridge to help people cross the creek; but there are people who already know how to build reliable bridges and you have to be able to either become one of those people or understand enough of their domain to collaborate with them.

I find a lot of great developers become pseudo-civil engineers. If you ask them to switch gears and write a video transcoder they're going to be about as useful as an intermediate programmer with zero-domain knowledge; despite having been writing software for civil engineers for that last 20 years and being in the top of their field... it's the domain knowledge that makes a big difference.

Not to mention that if they really are a great developer they'll just fork an open source project and be pretty much done.

No matter who you are, the more virgin code you write yourself today, the more immature and vulnerable your application will be.

Unless software creates such a large loss of life and disruption that the public has a similar outrage. The government will not act to regulate programming. In addition, it's neither in programmers or companies best interests to be regulated (except for programmers that are good at programming and companies that would like to pay a higher price for labor in exchange for quality).

The way things are going, I think that's a matter of time.

This is a false dichotomy: 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.

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.

Just to clarify one thing: I wasn't dissing Haskell or anything, I was just giving a real autobiographical detail. I actually did start learning Haskell, and at some point realised it wouldn't let me build anything new. I'd still love to learn Haskell and still plan to, because I like the art of programming. I just deprioritzed it compared to other things.

(And I totally forgot the Op was clojures’ author, that’s not the reason for the example!)

Your point is well taken, but I think the particular example of Python and Haskell doesn't fit your argument. I find that many programmers are not exposed to functional programming, so learning Haskell will provide a very different perspective on programming for someone who only knows imperative languages like JS or Python.

I believe that what you make in a language is explicitly influenced by the grammar of that language. Some things simply won't occur to you if you don't have the right vocabulary. It's the old "if all you have is a hammer, everything looks like a nail" saying. If all you have is Javascript, then distributed systems are going to be scary and hard. But if you can think in Erlang, not so much.

Likewise, I would encourage every programmer to learn a declarative language like SQL or a logic language like Prolog. Languages like these have very different properties than run of the mill imperative languages, which will surprise and enlighten many developers.

I think, like everything, it's a trade off.

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.

If neither of your developers has mastered software development, it doesn't matter which you pick - they're both going to need a lot of training and handholding.

If they have both mastered software development, then you may as well pick the specialist if you have a specialised task, or the generalist if you have a general task.

The point is that someone's ability to add business value (or practical value if you aren't in a buisiness, maybe artistic value in some settings) isn't a function of their programming languages and platform experience.

Realistically, nobody has mastered programming because they 'know X platforms'. All that experience guarentees is that they can reach their skill cap really quickly in any setting. This means nothing. It might even be a negative value-add if their skill cap is low enough. More information is needed to say if they are good programmers.

If you are hired as a developer you may be useful to have a "smorgasbord" of experiences, depending on the role. Working for a small company needing to hack something up quickly. Oh you've used AWS, Azure, React, Node, Haskell etc. You can pick the best tech for the problem. Someone who has only used C++ but 'gone deep' might be less useful here.

OTOH the C++ girl/uy might be more valuable in another company / team, whatever.

Nope. It's not even about being a "better developer". It's about being (and becoming) a master developer.

>If you are hired as a developer you may be useful to have a "smorgasbord" of experiences, depending on the role.

Then that company doesn't need a master, but just a generalist that can wear many hats with some competence.

>Someone who has only used C++ but 'gone deep' might be less useful here.

Which is neither here, nor there. The advice is how to become a master programmer (e.g. in C++), not how to become useful in a company that needs devs to tackle many roles.

The "doing the same thing" part, you added it.

You can very much be a master if you "worked for the whole life in the same programming language" and doing multiple things with it.

But even limited to a narrow scope, you can also be a master C++ programmer doing only games programming or network services programming.

You don't have to do some of this and some of that to become a master programmer.

You might not have the domain expertise to write a database or do DSP, but a domain expertise is something different from C++ mastery.

And learning varied "easy" pieces is exactly how anyone practising one instrument advances! The whole grades system used by the RCM is founded on that idea. What's "easy" to you at the time increases slowly with practice, but you learn a variety of pieces in a variety of genres that's at the level you're currently comfortable with.

If someone's going to pick an analogy, they should make sure it doesn't support the exact opposite of the point they're trying to make.

Programming is much closer to grand strategy than to rote pattern memorization, though there are patterns to be recognized in it.

Likewise performing music is a much broader subject than say just moving the pick across strings to a remembered melody. Even more so, composition.

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

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.

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

I think the comment still stands for most mere mortals.

But don't:

- jump on the first tech/instrument. It's a lottery.

- keep changing again and again. You'll never develop mastery. There is so much you can do by being a jack of all trade.

- stay on what you master and never go out of your comfort zone. Still will make you stale.

How many will become obsolete during a musician's career? When is the last time grand piano underwent a significant upgrade? : )

Accordion is closer but still rarely uses polyphony.

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

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

Elements I, 32 (triangle sum theorem) https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.htm... looks lopsided - especially compared with this nicely symmetrical one: 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...). 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?

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.

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

Another aspect of the symmetrical stackexchange diagram (two alternate interior angles), and Euclid's lop-sided one is that Euclid's is slightly simpler (one alternate interior angle, and one corresponding angle).

But from another perspective, the symmetrical one is simpler, because its symmetry allows it to be remembered as symmetry, and only recording one side.

Further, although stating it is symmetrical may require more information to record than just explicitly stating both sides if you only record one theorem, if you record a corpus of theorems and symmetry is common over that corpus (which it is), it can be stated with less information. (i.e, like using shorter words for frequently used concepts).

But this is only for the proof details; I'm not sure how it applies to the theorem as a reusable component, where you don't have to worry about the details.

    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.

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.

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.

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

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

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.

In your case, assuming that your field is "web development", this means getting deep mastery in web development. You know which language and framework you want to use in the backend for low traffic websites, and you know what you want to use for high concurrency websites. You know very well the relative strengths of PHP / Laravel and (say) Elixir / Phoenix.

If more on the frontend side of things, you feel comfortable enough to switch between various frameworks with a short learning curve, and you understand _why_ new frameworks and new ideas around how to build webapps are appearing. You also know when to use vanilla-js and when to use react. When to use ES6, TypeScript and Clojurescript

My interpretation of what might be counter-productive to mastery, is to get into webdev today, data science two years from now, distributed systems another 2 years, and then after that desktop applications etc whatever, based on the current trend. A careful judgement call needs to be made carefully when switching domains.

Ultimately every domain is both very wide and very deep, and it's hard enough to get mastery in one, let alone jump into a new field that your peers have already been doing since the beginning of their careers.

Working on many different technologies is daunting at the beginning but in time you’ll see that even if the specific invocations change, the core concepts of programming from responding to events to handling data changes are quite stable and comparable moving from one environment to another.

Sure it’ll be harder then to find work than the generic guy who lucked out on the resume keyword lottery, but wast domain knowledge will open up quite many doors outside basic programmariate

The real issue then becomes how to put broad knowledge into the resume and how to estabilish oneself as knowledgeable of many instead of expert of one, the latter being far easier via blogs, articles etc.

Well, I don't think anybody wants to, but after a point, it becomes a sad reality.

Realize that the people who contribute to Laravel and to PHP are trying to solve real problems, and there implement patterns used in other frameworks and languages.

Without deep-diving some, you won't be able to recognize those patterns in other frameworks and languages.

For instance, I did a very brief stint with Ruby on Rails. I've also tried out Django with Python, Laravel with PHP, Phoenix with Elixir, and Caliburn with C#.

In each of these cases, I became more familiar with common patterns (Model-View-Whatever, Dependency Injection), and how each framework attempted to solve the problem.

So to answer your question: yes, "mastering" a technology can transfer to another similar technology. So don't be afraid to dig in, best of luck!

What entire premise? What is this in response to?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

What sets them apart is not necessarily creativity, but rather consistency, quality, and a set of ethics. An engineer has to ensure that what they build works, is robust to bad inputs, robust to errors and failure situations, and is maintainable by others. Consistent practice and tools is key to this and software is only starting to catch up to other engineering practices.

However, many developers see themselves instead as artists, and your comment is a classic example. You want to "create novel things," "ideate," and essentially produce pieces of unique art. You want to be the hero, with irreplaceable skills. This isn't a bad thing, there is always a place in the world for artists. We need artists!

However, art is not engineering, and it shouldn't be too surprising that the big companies want engineers, not artists. They want people who can build things reliably, predictably, work on a team, and yes be replaceable. These days it's more likely that you have to replace an engineer because thy leave for new work rather than are fired.

Both art and engineering are great professions, but different.

The tension between creativity and conventions is fascinating.

I recently read a book about writing (ostensibly editing) called The Story Grid:

https://storygrid.com/

Here's a video summary:

https://www.youtube.com/watch?v=y3-dw9cIx2o

It argues that the most important thing for an author to understand is the genre they're working in because the genre gives the author conventions. Violate any of them and you're setting yourself up for failure.

The best authors find creative, non-obvious ways to innovate conventions while still adhering to them.

Although some will view this advice as sucking the creativity out of the writing process, the author argues it does exactly the opposite.

Frustrated authors find the idea of genres and conventions stifling. These are the ones who abandon conventions altogether. They are punished by pouring heart and soul into a work that doesn't sell and which they themselves often know doesn't work but can't explain why.

I think a great example of this philosophy in music, is Jack White with the White Stripes. He held to a very rigid set of rules which resulted in very simple, straightforward songs. What was great about that was that it gave him a platform at live shows to perform amazing virtuoso solo stuff on top. The platform, with its simple rules and structure, allowed him to perform those solos. Had he come on stage and just randomly started playing solos from start to finish, it wouldn't have the same effect and would probably just be quite aimless and noisy.

It's true in software too. When building a web app tools like webpack et al exist to solve boring, routine problems in a standard way that you don't have to spend much time worrying about (webpack config issues jokes aside) so that you can focus all your creativity on what actually matters and what is interesting and unique - what your app does!

I think it agrees on your point.

The same applies for software engineers. The method of using the common tools is identical across many web applications - the creativity is in which of these tools, for which set of subtasks are selected for this set of requirements.

You get to be creative today. Which package manager are we going to use on our new project: npm, bower, or yarn?

Whoopty freakin' doo!

IME, the easier the scaffolding gets, the more creativity offered to the business. That's how I see my job as an engineer/systems designer: enabling the business to try new things more quickly.

[0] I've seen a lot of engineers justify rewrites because "these better tools will let us make a cleaner codebase" but if done with a focus on the tooling, instead of a focus on the coding implementation choices that led to a messy codebase in the first place, it often just burns a lot of money replacing an old messy codebase with a new messy codebase.

As an engineer, it's not your job to be creative. The only creativity that happens in the company is that of C-suite people (who first comes up with what you'll build) and that of the sales staff (who figure out how to turn those half-baked ideas of the C-suite folks into something that can be sold).

Over the past months I've been having this crushing realization that - at scale - you can be either a creative manager or an assembly-line developer. You can't be a creative development. There are few R&D jobs here and there where the people with technical skills get to be creative, but they're scarce.

Or we can just abandon practice of referring to development as engineering, and treat every project like artisinal craft work.

I fully agree with you that there is a lot of wheel reinvention in JS, but given that you can use React to build native/mobile/web apps it means that people are empowered to build tools higher up the abstraction layers (see SICP) without needing to peek down below (until the abstraction leaks, and they always do).

That said, most software projects I've seen have been held back by human issues, poor communication of business needs or API design. Automation won't fix that so most your production line developers will still have a gig while human-written software is around.

Thankfully, they're also well positioned to transition into fixing the automators which will have bugs. :)

I've seen too much over engineered crap to believe this. In many case the over engineering was an attempt at making us more like production line workers in the first place with the "architect" breaking things down into cookie cutter steps.

There is also the problem with user expectations, there are several "production line" like environments available but no one likes the trade off of inflexibility.

I actually agree with this sentiment, although many others to hate on you on this thread.

And it will happen, just like what happened to labor workers who used to make a good living working for Ford at production line. You can already see plenty of evidence when you see how all developers are forced to use package managers and follow "coding guidelines", and so forth. These efforts will all lead to a more and more structured way of building things, which then can be replaced by machines.

And these naive and passive programmers who thought they were set for life by taking a coding bootcamp and getting a programming job will suddenly find that it's not as lucrative anymore.

The point I was trying to make was: Don't be these people who live a passive life and do what others say, thinking just because programmers make a lot of money, all you gotta do is "become a good programmer" and you'll be set for life. You should have a meaning in life. Otherwise you'll find yourself in the similar situation as these Ford production line workers.

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.

Code is phenomenally expensive.

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

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.

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.

> And, you need to be careful to recognize the actual game involved. Programming mastery has little to do with languages, paradigms, platforms, building blocks, open source, conferences etc. These things change all the time and are not fundamental.

I learn new programming languages to keep up with the market because the market isnt fair and loves hyped up new stuff and to also provide for myself and family, if I stayed with the programming language I had from high school, I might be a master in Visual Basic but also likely live not as well. In the end, its people's choice and tradeoff I guess.

Unless of course this person can supply a empirical causation, he isnt right.

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.

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.

Disruption does not occur that quickly that proven-capable humans suddenly become utterly useless. If a major tech company with a good reputation starts blogging about it, maybe read a few articles on it and see if it's interesting enough to spend some time on.

There's a neat bias in development where a disruption implies that people above the developers will 100% use the new disruption tech perfectly, and somehow, only developers are the ones at risk of being left behind. Change usually goes much slower, and usually there is an experimental phase before suddenly betting your entire production infrastructure on new X technology. You can also safely bet there will be tutorials and videos to quickly bring you up to speed if the technology is that disruptive.

Also, you have to remember that technologies come quickly but they can also leave quickly as well, making your time spent quickly adjusting to them worthless. Ask Silverlight developers.

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

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