Hacker News new | past | comments | ask | show | jobs | submit login
On becoming a better developer (2015) (gist.github.com)
359 points by kristianp on Apr 18, 2018 | hide | past | favorite | 113 comments

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

I think you're right.

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

>programmers with little experience in a domain...write software to solve problems in that domain and iterate...Disruption!

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.

It all has to start somewhere, I agree.

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.

I don't think you understand what domain knowledge means. If the civil engineer is a user of VLC, Youtube, etc. then they do not have "zero domain knowledge" when writing a transcoder.

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.

The notion of a regulated Engineering profession really came about when some very famous bridges started to collapse under load. In response to this, there was public outrage and distrust in governmental projects such as bridges. Thus, the government conceived a program where engineering labor supply is regulated through training and association standards.

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

> Unless software creates such a large loss of life and disruption that the public has a similar outrage.

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

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

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.

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


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

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

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 don't think it's an either-or thing. Getting better at programming will make you more effective in whatever domain you are working in. I think it's generally good to work on concrete projects but "what can I actually achieve with code I write" is heavily influenced by general programming skills. In my current domain of VR development the quality of product I can build is at least as influenced by my general programming skill set as by my domain expertise. Getting better results continues to require me to develop more expertise both in the domain and in programming (and I am already advanced / expert level in both so I don't think this applies only to relative beginners).

I (pretty much) agree. I would suggest that other domains (not unlike 3D programming) that Rich Hickey learnt in order to "do something" were "marketing", "OSS cat herding" and others.

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

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

Those concerns are orthogonal to the type of mastery Rich is talking about.

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.

I agree. If you have someone who shows mastery in one area, you see what level they can attain. With a generalist (assuming no mastery), it's a gamble. They might not be able to master anything.

This article has an idea of what a "Better Developer" is, which is kind of like a True Scotsman that must eat Haggis (or not!).

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.

>This article has an idea of what a "Better Developer" is, which is kind of like a True Scotsman that must eat Haggis (or not!).

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.

You can’t ever be a master if you worked for the whole life in the same programming language doing the same thing. You will be a narrow-sighted, maybe even very good, C++ developer that thinks to be a master. A master has to have a huge amount of experience in a lot of different problems, domains and programming languages. Otherwise he is just a specialised plumber, it won’t have the wide experience needed to engineer any kind of system.

>You can’t ever be a master if you worked for the whole life in the same programming language doing the same thing.

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.

You’ll never be a master because you are missing a lot of solutions, paradigms and techniques that are common in other languages and that you will never learn staying forever in the same language. Also I would like to see how you can become a master in web development using C++. You will always be castrated compared to someone else that has a much vaster experience with multiple languages and domains.

I think I can support this notion with something a little more concrete. I program C++ (13 yrs) and I learned javascript and web dev 8 years ago. don't consider myself a master at either. But, having broad coverage over and aptitude in both of these realms has had a huge impact on my ability to make an impact in the real world, working at a robotics company that heavily leverages these technologies. There are large rifts between teams that form due to the relative scarcity of "cross-pollinated" contributors.

I think that Linus Torvalds is a master of operating system development, even though he's done all his work in C. And I'm pretty sure that he doesn't care about ever being a master in web development (just as most web developers are probably not interested in becoming kernel developers).

It's an odd analogy. Musicians frequently advance by learning multiple instruments and genres. Your drums example is good, and there are lots more. Piano's a very common instrument to start with, because it teaches you a bit of everything: rhythm, melody, harmony, coordination, sight reading, and leads easily into learning music theory, and musicians on all instruments often have a piano background. I don't know a single concert violinist that isn't at least competent at strumming out a few chords on an acoustic guitar. Woodwinds players often follow a path of increasingly difficult embouchures, e.g. recorder -> flute -> oboe.

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.

Let's say chess players don't get to top level by playing checkers or Go ;) Actually some grandmasters do, eg. Ivanchuk does play checkers and Morozevich does play Go - and it may have mildly beneficial effect, broadening your horizons etc. - but it's not the primary training you need

That is because unlike programming, chess nowadays does not utilize too many general skills. Good positional play for instance won't help you enough against an opponent who has memorized many patterns. This is why it was so easily tackled by computers compared to Go or more complex grand strategy games.

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.

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.

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

Or in Africa. It's very common, depending on the country, to know 2 or 3 colonial languages and then speak a handful of different tribal languages on top of that. And all very competently. It's simply a necessity of life in a lot of places.

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.

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

Most people I've met who have studied 10+ languages learned at least two or three to fluency before they developed a "language collecting" habit. But one does come across the occasional total dilettante, too.

First try several things to find something you like, then focus on one thing to become good, then go back to trying out several things to get better at your general skill.

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.

I wouldn't. The code I wrote as an experienced backend engineer is much nicer and easier to understand compared to someone generic who knows the basics but not the finer details of the language.

Musical instruments don't change nearly as much as programming frameworks, environments etc.

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

Latest update on the general idea was somewhere in 80s with the advent of polyphonic multitimbre keyboard synthesizers.

If you go to music school to learn violin, saxophone etc. you will have mandatory piano class, but pianist won't have mandatory violin class.

This is mostly because solo violin does not teach enough coordination. Though concert performance practice may help with that it is still less involved. Performing sequentially compared to parallel.

Accordion is closer but still rarely uses polyphony.

I don't think this has anything to do with coordination. Piano is considered the master instrument. You can pick something which require more coordination and you still need to take piano lessons.

It really depends. Sometimes a specialised developer would be more helpful than an general developer.

Also, to become a better conductor or composer you might need to be fairly comfortable with multiple instruments, no?

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.

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.

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.

Yep. My descent into that Dunning-Kruger valley came hard and fast as soon as I started working with people who were actually good.

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

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.

Please bear with me while I draw a parallel:

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?

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.

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

Thinking about the beauty of proofs, as imdicated by simplicity, and how breifly they can be encoded (information-theoretic version of occam's razor):

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.

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

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.

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

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

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.

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.

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

Agreed, though I would add that in terms of being a better programmer rather then Laravel Developer, you have to get really good at deconstructing frameworks. Essentially you have to understand all these tools and frameworks are just normal code that have been bundled together to give you some magic methods. If you can deep dive into frameworks with ease and understand what they do then you'll be successful.

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.

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.

I think it's less about becoming mastery of tools. I don't think that is what's being advocated, and at least not my interpretation.

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.

You should really not cater to recruiters only looking for x years of experience in keywords y and z

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.

> You should really not cater to recruiters only looking for x years of experience in keywords y and z

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

For your comment about Laravel and PHP, I think it is a valuable exercise to complete a project using a framework like Laravel and PHP.

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!

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

What entire premise? What is this in response to?

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

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.

Thanks man.

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.

Just say you're welcome.

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.

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

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.

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.

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.

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.

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.

what is the supercomprensation recovery phase?


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.

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.

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

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.

I think what you are struggling with is not "developer" vs "production line worker," but rather "artist" vs "engineer." I'd go so far as to say artists don't belong in most development groups, engineers do.

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.

And I'm sure it WILL be replaceable because we are increasingly surrounding ourselves with these uniform ways of doing things.

The tension between creativity and conventions is fascinating.

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


Here's a video summary:


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 like this idea. I think a good analogy is creativity being like a raw force, and a set of rules and conventions giving it direction so that it can be focused into a jet that can be pointed at a specific place and be really useful, rather than just spraying randomly around and probably not being all that useful.

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'm currently reading "Story: Style, Structure, Substance, and the Principles of Screenwriting" https://mckeestory.com/

I think it agrees on your point.

Civil engineers also use same common brands of cement and standard steel girders. They also often re-use the same blueprint for multiple buildings. The creativity isn’t in the form but the ordering and process in which a given form is constructed over a particular piece of land - this one.

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.

That might be the most depressing thing I've heard all day.

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!

I've never seen a project live or die by package management[0], and I've never seen automated tooling come close to solving the real problem facing most developers: irreducibly complex business logic. Every once in a while one gives you a good head start on the boilerplate around the business logic - Rails a while back, React now - but it's far from solving the "every business is a little bit different" problem.

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.

It's even worse.

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.

But do you really want to be the developer who has to debug 'creative' code after the original dev has left? It may not be as much fun, but I don't think that assembly-line development is entirely a bad thing. Even something minor like style conventions: far better to fit into the assembly line of your team's style guide than produce a project where every file is written in a slightly different way. Is this particular variable supposed to be const b/c it is all caps, or not? The last class followed that standard, but who knows? Small example, but can be applied to larger things as well. Last month I had to 'maintain' an application for a small business that had seen too much creativity from contractors over the years, and it seemed like every single one chose a different language.

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

The package manager you get to use today depends on variables that are totally independent from your own creative process. Perhaps it’s the one that supports some tooling used by infra or security or whatever. Unless it’s an ungodly train wreck of a tool that is significantly interfering with your output, it’s not your job to reinvent package management. I’d scream to the high heavens if I’d have to resolve these problems every other project I take on - incidentally, stacks and platforms are such a moving target that I often have to do so anyway.

Are you still programming everything in ones and zeros in a tape to be run by a Turing machine? If not, you're using tools to get your job done. It turns out that most tools allow you to get your job done quicker so you have more time to focus on other things.

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

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.

> The way we produce code is so ruinously expensive that nearly everyone in this industry accepts the tradeoff between developer velocity and product quality

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.

> Turning developers into production line workers is precisely what needs to happen

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.

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.

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

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.

Software development scales poorly. This was noted a long time ago, an I’ve not seen anything that fundamentally falsifies the Fred Brooks view. So to make the expected cost of software lower, shouldn’t we be looking to smaller-scale, more individualistic ways of working?

Uhm, sorry that’s a bit too paranoid. The existence of ISO/IEC, DIN and the plethora of standard bodies haven’t made Engineering less creative or remunerative. Sure, you can’t craft your own custom bolt but you also don’t have to every time. Which is a good thing also

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.

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.

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?

I don’t think I could say it better than Rich in the last paragraph:

> 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 disagree because even the Actor Model was inspired by Lisp and Physics. Why are we so against different ideas in programming? Theres no pure land ivory tower in development, whatever works will work because they are tools to a craftsman, you can't compete with new tools like the cloud deployments if you're still fighting with an old school server under the same load and achieve cost efficiency, programmers need to constantly relearn and reshape to keep up with the trades and the times.

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.

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.

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.

>but it is easy to become irrelevant if you have no breadth and a disruption occurs.

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.

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.

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.

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

Couldn't agree more

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact