11 ms·

On becoming a better developer (2015)

359 points by kristianp 9y ago

mnm1 9y ago
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.
Noumenon72 9y ago
Reminds me of how "confusing the muscle" came and went out of style as people realized you need specificity of training and you need to train a muscle with the same motion during its supercompensation recovery phase for it to further grow.
- mlevental 9y ago
  what is the supercomprensation recovery phase?
  - Tuna-Fish 9y ago
    https://en.wikipedia.org/wiki/Supercompensation https://en.wikipedia.org/wiki/Supercompensation As a gross oversimplification: when you train a muscle hard, it accumulates low-level damage. This is why if you train continuously without any recovery, your ability level goes down, not up. The recovery phase is when your body repairs all that accumulated damage and builds the muscle back. Only, it doesn't stop at the level you started at, it goes past that and makes it a little stronger than it was. This is the supercompensation phase. If you just let it be, performance will eventually return to where you started at. But if you train again during this phase, you can reset the cycle, starting from a higher point.
bsaul 9y ago
"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.
- another-one-off 9y ago
  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.
  - mruniverse 9y ago
    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.
- some_account 9y ago
  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.
- V-2 9y ago
stonemetal 9y ago
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.
- ra273 9y ago
  The essence of the article is in honing one's learning and problem solving abilities. Neither are likely to become redundant in our lifespans. React Native, GraphQL, Rust, etc. are for example all very transient skills. Focus on fundamentals.
- nnq 9y ago
  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.
- FLUX-YOU 9y ago
  >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.
cocktailpeanuts 9y ago
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.
- meric 9y ago
JimRoepcke 9y ago
The first sentence is "Sorry, I have to disagree with the entire premise here." What entire premise? What is this in response to?
- kens 9y ago
  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-achievements-how-to-level-up-as-a-developer/#comment-287120251 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.
  - BrissyCoder 9y ago
    Thanks man.
    - edanm 9y ago
      Just FYI since you appear to be a new user: on Hacker News, writing comments like yours is considered bad form. You should instead just upvote the parent comment, that's the HN way of showing appreciation. The reason is that, at least in theory, every comment on HN should be adding value for people to read, and reading a bunch of "thanks" messages is just a waste of time. Much better to just have the original comment appearing higher because it got more votes.
      - 0xBA5ED 9y ago
        Just say you're welcome.
forkLding 9y ago
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.
- dkasper 9y ago
  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.
  - forkLding 9y ago
    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.
- jkoudys 9y ago
  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.
hyperpallium 9y ago
Abraham Lincoln studied Euclid to become a better lawyer (to learn how to "demonstrate"). I've just studied a tiny bit of Euclid, and his design of lemmas (technical theorems, not beautiful in themselves, whose beauty is neatly meeting needs in higher-level theorems), is program decomposition into modules, that you can see. I can't be sure yet, but I feel I'm already thinking more clearly. EDIT Euclid means "renowned," from eu "well" + kleos "fame". This jibes well with the team-theory: "Because the lack of biographical information is unusual for the period (extensive biographies are available for most significant Greek mathematicians for several centuries before and after Euclid), some researchers have proposed that Euclid was not, in fact, a historical character and that his works were written by a team of mathematicians who took the name Euclid from the historical character Euclid of Megara (compare Bourbaki)." https://wikipedia.org/wiki/Euclid#Life https://wikipedia.org/wiki/Euclid#Life
- n4r9 9y ago
  I had the same insight from the opposite direction. My background is mathematics but have been struck by the similarities between refactoring code and splitting a proof into lemmas, corollaries and theorems. There's also an art to creating good definitions during mathematical exposition, which is akin to creating variables to encapsulate the right data and naming them well. BTW Pythagoras is another ancient Greek who may well not have been a historical character.
  - hyperpallium 9y ago
    Please bear with me while I draw a parallel: Elements I, 32 (triangle sum theorem) https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.html https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.htm... looks lopsided - especially compared with this nicely symmetrical one: https://math.stackexchange.com/q/2727737 https://math.stackexchange.com/q/2727737 But I, 32 also shows that an exterior angle is the sum of the two opposite interior angles - which seems an odd, weird thing to prove, but fits nicely into other theorems. The one I've seen is the proof of the inscribed angle theorem, III, 20 (https://mathcs.clarku.edu/~djoyce/elements/bookIII/propIII20.html 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?
dwaltrip 9y ago
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).
- ra273 9y ago
  Exactly. Software is merely a medium to express such ideas. Only charlatans occupy themselves with the burden of polyglotism.
twblalock 9y ago
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.
- jkoudys 9y ago
  Yep. My descent into that Dunning-Kruger valley came hard and fast as soon as I started working with people who were actually good.
- wool_gather 9y ago
  This is a frustration I have with my current position. I'm the second most experienced person on the team, and most knowledgeable about our platform. And I'm...not that experienced or knowledgeable. Big fish, small pond has never appealed to me. It gives me no one to check my ideas with, and pulls me, as much as I consciously resist, down the path to being a know-it-all Dunning-Kreuger assbutt.
  - 0x445442 9y ago
    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.
laktek 9y ago
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.
joelcornett 9y ago
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.
BrissyCoder 9y ago
What is this in response to? What/whose "entire premise" is he disagreeing with?
edanm 9y ago
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. :)
- lifeisstillgood 9y ago
  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.
- alpos 9y ago
  >In choosing between learning Haskell or learning 3d programming... This is a false dichotomy: https://wiki.haskell.org/Game_Development https://wiki.haskell.org/Game_Development As the linked response from Rich Hickey pointed out, you can do anything in any (Turing complete) language. I agree with the notion behind your decision to focus on real results though. I think that is actually closer to the mastery part of the progression from beginner to master. I think when one can deeply realize that programming is just a tool to achieve other things, then one is leaning towards the mastery end of the scale. That's not a hard rule though, I think part of the problem we all have discussing this sort of thing is that we have a hard time consistently measuring where a person is on that progression.
icc97 9y ago
I think there's a quote from Paul Graham somewhere along the lines of 'T-Type learners': > Like paint drops rolling down from a paint stroke, the breadth is there but at certain points the paint rolls down creating deep lines So you can skim the surface but at some points you have have real focus. You need to choose these carefully and dive deep into them.
- AstralStorm 9y ago
  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.
carlsborg 9y ago
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.
TheCapeGreek 9y ago
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.
- deleted 9y ago
  [deleted]
- lghh 9y ago
  The best way to circumvent this feeling is to learn how programming works rather than how PHP and Laravel work. If you know what a web server is, how to scale it, know a little about web security, and how to write OOP well you're in very good shape. Don't learn the intricacies of Laravel, you can pick those up on the job. Learn enough about PHP to be able to identify what goes into a programming language and to be able to look at other languages and tell how they are different and the same past one using the word "const" instead of "let".
  - jxub 9y ago
    Or become an ES6 ninja and use both "const" and "let";). On a more serious note, it's strange how has "let" became an identifier for mutable data in js, while eg. ML uses it for the opposite if I recall properly.
    - chillee 9y ago
      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.
Philipp__ 9y ago
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.
greenhatman 9y ago
I look at this in the same way that I used to look at creating Diablo 2 characters when I was a kid. You're building a skill tree. The first thing you need to take into consideration is whether you're playing with other people or solo. If you're playing solo, you need to be more of a generalist. You need to pick just the right skills so that you're able to handle an scenario that the game will throw at you. You need to be able to deal at least two types of damages, for when you're facing monsters that are immune to some types of damage. You also need decent defence. And preferably a way of travelling over obstacles. When you're playing with other players, you can go for only one type of damage, and pick other skills that amplifies or synergises with this skill. You actually don't have to focus on damage much, if you can tank and take damage well to protect other fragile players who do lots of damage. Or if you focus on doing lots of damage but you're a bit of a glass canon, you just need to make sure that you're playing with another player than can pull the attention of dangerous monsters. In both scenarios you need to pay attention to how you build your skill tree. Just the considerations are a bit different. I tend to pick skills and technologies to learn that are on different parts of the stack, because I often work alone or in small teams. I need to be able to create a whole app with front-end and back-end and manage the infrastructure. So I only pick one front-end framework, one back-end framework, and one or two infrastructure tools. It's a tall order, but you can do it if you don't spend time learning things you don't need to. On the other hand, people who work in large teams are usually better off focusing on their niches. So if you're a front-end dev, you can learn 2 or 3 different front-end frameworks, and it will make you a more effective front-end developer in both. It's just that you get diminishing returns with each new front-end technology that you learn. But this is work it if you're in a position where the other parts of the stack are handled by people who focus all their efforts to be exceptionally competent there.
- jcadam 9y ago
  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. ;)
deleted 9y ago
[deleted]
Daycrawler 9y ago
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-achievements-how-to-level-up-as-a-developer/#comment-287120251 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.
dale14 9y ago
Couldn't agree more
blauditore 9y ago
> 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.
lmilcin 9y ago
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.

359 points by kristianp 9y ago

mnm1 9y ago

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.

Noumenon72 9y ago

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

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

bsaul 9y ago

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

another-one-off 9y ago
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.
- mruniverse 9y ago
  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.
some_account 9y ago
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.
V-2 9y ago

stonemetal 9y ago

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.

ra273 9y ago
The essence of the article is in honing one's learning and problem solving abilities. Neither are likely to become redundant in our lifespans. React Native, GraphQL, Rust, etc. are for example all very transient skills. Focus on fundamentals.
nnq 9y ago
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.
FLUX-YOU 9y ago
>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.

cocktailpeanuts 9y ago

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.

meric 9y ago

JimRoepcke 9y ago

The first sentence is "Sorry, I have to disagree with the entire premise here." What entire premise? What is this in response to?

kens 9y ago
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-achievements-how-to-level-up-as-a-developer/#comment-287120251 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.
- BrissyCoder 9y ago
  Thanks man.
  - edanm 9y ago
    Just FYI since you appear to be a new user: on Hacker News, writing comments like yours is considered bad form. You should instead just upvote the parent comment, that's the HN way of showing appreciation. The reason is that, at least in theory, every comment on HN should be adding value for people to read, and reading a bunch of "thanks" messages is just a waste of time. Much better to just have the original comment appearing higher because it got more votes.
    - 0xBA5ED 9y ago
      Just say you're welcome.

forkLding 9y ago

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.

dkasper 9y ago
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.
- forkLding 9y ago
  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.
jkoudys 9y ago
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.

hyperpallium 9y ago

Abraham Lincoln studied Euclid to become a better lawyer (to learn how to "demonstrate"). I've just studied a tiny bit of Euclid, and his design of lemmas (technical theorems, not beautiful in themselves, whose beauty is neatly meeting needs in higher-level theorems), is program decomposition into modules, that you can see. I can't be sure yet, but I feel I'm already thinking more clearly. EDIT Euclid means "renowned," from eu "well" + kleos "fame". This jibes well with the team-theory: "Because the lack of biographical information is unusual for the period (extensive biographies are available for most significant Greek mathematicians for several centuries before and after Euclid), some researchers have proposed that Euclid was not, in fact, a historical character and that his works were written by a team of mathematicians who took the name Euclid from the historical character Euclid of Megara (compare Bourbaki)." https://wikipedia.org/wiki/Euclid#Life https://wikipedia.org/wiki/Euclid#Life

n4r9 9y ago
I had the same insight from the opposite direction. My background is mathematics but have been struck by the similarities between refactoring code and splitting a proof into lemmas, corollaries and theorems. There's also an art to creating good definitions during mathematical exposition, which is akin to creating variables to encapsulate the right data and naming them well. BTW Pythagoras is another ancient Greek who may well not have been a historical character.
- hyperpallium 9y ago
  Please bear with me while I draw a parallel: Elements I, 32 (triangle sum theorem) https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.html https://mathcs.clarku.edu/~djoyce/elements/bookI/propI32.htm... looks lopsided - especially compared with this nicely symmetrical one: https://math.stackexchange.com/q/2727737 https://math.stackexchange.com/q/2727737 But I, 32 also shows that an exterior angle is the sum of the two opposite interior angles - which seems an odd, weird thing to prove, but fits nicely into other theorems. The one I've seen is the proof of the inscribed angle theorem, III, 20 (https://mathcs.clarku.edu/~djoyce/elements/bookIII/propIII20.html 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?

dwaltrip 9y ago

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

ra273 9y ago
Exactly. Software is merely a medium to express such ideas. Only charlatans occupy themselves with the burden of polyglotism.

twblalock 9y ago

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.

jkoudys 9y ago
Yep. My descent into that Dunning-Kruger valley came hard and fast as soon as I started working with people who were actually good.
wool_gather 9y ago
This is a frustration I have with my current position. I'm the second most experienced person on the team, and most knowledgeable about our platform. And I'm...not that experienced or knowledgeable. Big fish, small pond has never appealed to me. It gives me no one to check my ideas with, and pulls me, as much as I consciously resist, down the path to being a know-it-all Dunning-Kreuger assbutt.
- 0x445442 9y ago
  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.

laktek 9y ago

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.

joelcornett 9y ago

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.

BrissyCoder 9y ago

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

edanm 9y ago

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

lifeisstillgood 9y ago
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.
alpos 9y ago
>In choosing between learning Haskell or learning 3d programming... This is a false dichotomy: https://wiki.haskell.org/Game_Development https://wiki.haskell.org/Game_Development As the linked response from Rich Hickey pointed out, you can do anything in any (Turing complete) language. I agree with the notion behind your decision to focus on real results though. I think that is actually closer to the mastery part of the progression from beginner to master. I think when one can deeply realize that programming is just a tool to achieve other things, then one is leaning towards the mastery end of the scale. That's not a hard rule though, I think part of the problem we all have discussing this sort of thing is that we have a hard time consistently measuring where a person is on that progression.

icc97 9y ago

I think there's a quote from Paul Graham somewhere along the lines of 'T-Type learners': > Like paint drops rolling down from a paint stroke, the breadth is there but at certain points the paint rolls down creating deep lines So you can skim the surface but at some points you have have real focus. You need to choose these carefully and dive deep into them.

AstralStorm 9y ago
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.

carlsborg 9y ago

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.

TheCapeGreek 9y ago

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.

deleted 9y ago
[deleted]
lghh 9y ago
The best way to circumvent this feeling is to learn how programming works rather than how PHP and Laravel work. If you know what a web server is, how to scale it, know a little about web security, and how to write OOP well you're in very good shape. Don't learn the intricacies of Laravel, you can pick those up on the job. Learn enough about PHP to be able to identify what goes into a programming language and to be able to look at other languages and tell how they are different and the same past one using the word "const" instead of "let".
- jxub 9y ago
  Or become an ES6 ninja and use both "const" and "let";). On a more serious note, it's strange how has "let" became an identifier for mutable data in js, while eg. ML uses it for the opposite if I recall properly.
  - chillee 9y ago
    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.

Philipp__ 9y ago

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.

greenhatman 9y ago

I look at this in the same way that I used to look at creating Diablo 2 characters when I was a kid. You're building a skill tree. The first thing you need to take into consideration is whether you're playing with other people or solo. If you're playing solo, you need to be more of a generalist. You need to pick just the right skills so that you're able to handle an scenario that the game will throw at you. You need to be able to deal at least two types of damages, for when you're facing monsters that are immune to some types of damage. You also need decent defence. And preferably a way of travelling over obstacles. When you're playing with other players, you can go for only one type of damage, and pick other skills that amplifies or synergises with this skill. You actually don't have to focus on damage much, if you can tank and take damage well to protect other fragile players who do lots of damage. Or if you focus on doing lots of damage but you're a bit of a glass canon, you just need to make sure that you're playing with another player than can pull the attention of dangerous monsters. In both scenarios you need to pay attention to how you build your skill tree. Just the considerations are a bit different. I tend to pick skills and technologies to learn that are on different parts of the stack, because I often work alone or in small teams. I need to be able to create a whole app with front-end and back-end and manage the infrastructure. So I only pick one front-end framework, one back-end framework, and one or two infrastructure tools. It's a tall order, but you can do it if you don't spend time learning things you don't need to. On the other hand, people who work in large teams are usually better off focusing on their niches. So if you're a front-end dev, you can learn 2 or 3 different front-end frameworks, and it will make you a more effective front-end developer in both. It's just that you get diminishing returns with each new front-end technology that you learn. But this is work it if you're in a position where the other parts of the stack are handled by people who focus all their efforts to be exceptionally competent there.

jcadam 9y ago
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. ;)

deleted 9y ago

[deleted]

Daycrawler 9y ago

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-achievements-how-to-level-up-as-a-developer/#comment-287120251 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.

dale14 9y ago

Couldn't agree more

blauditore 9y ago

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

lmilcin 9y ago

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.