Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years.<p>I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it certainly doesn't mean I write code that doesn't need refactoring. Maybe my designs are better than they used to be — I think so — but often that's because I developed the design <i>more</i> incrementally through refactoring, rather than <i>less</i> incrementally by planning.<p>I do avoid a lot of errors by thinking through the consequences of a choice before taking action, in a way that I couldn't always do. But often that choice is specifically the choice to plan out a big design at the start of a project.<p>Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.<p>The author describes a lot of anxiety and guilt about doing things imperfectly. I think that's a big obstacle to improvement — other people can pick up on that and will be reluctant to give you feedback, and feedback from other people is a really fast way to improve. Also, it tends to shunt you into tasks that don't challenge you enough — it pushes you to avoid risk, and pushes other people to not ask you to do things that are at the limit of your abilities. This is precisely the dynamic Atwood was trying to combat by telling his story.
I think one word would shed light on such anecdotes: deliberate practice. Countless literature and researches have pointed out that simply doing more would not bring much improvement but find out what is missing and practice it to perfection then move to another weaknesses is the best way to achieve top performance, be it in sport, in music or other fields. Like someone who want to learn chess; simply plays a lot each and every day will improve his ELO slowly but it will stall after a while (say at the level of a club player) and he can almost certainly never attain the mastery. In opposite, someone who seeks guidance, study and practice to fix his weaknesses and perfect his technique will improve vastly more in the same amount of time. Effective practice and coaching is also the only difference between merely very good players and grand masters. I can’t imagine why it should be different in the field of programming and software engineering. Someone who writes thousands sloppy games might have learned how to do them faster (and maybe better) but he still learned nothing more about complex systems or secure systems. Only with intense study and practice he can master such stuffs effectively.<p>The Talent Code of Coyle is a good book to start reading about deliberate practice.
I've been coding intensively for more than half of my life from a young age - I'm approaching 16 years of experience now. Also, I've been doing it quite intensively (I was writing games when I was still in school before studying software engineering at university, then I worked for 14 different companies; some startups and some corporations in about 10 different industries. I've completed projects in at least 7 different programming languages). Also I've always been working on a side project during nights and weekends; mostly open source.<p>I have mixed feelings about the ceramics anecdote because I've met some people who have been coding a long time and producing large quanities of code but it's not good quality. To write high quality code, you need to enjoy the process and be adaptable. You need to have been exposed to a lot of different kinds of projects and management cultures.<p>Also, the most frustrating thing is that other people who are not good coders don't recognize straight away who is a good coder. Often, it takes a whole year to prove yourself. However, good coders usually know straight away who a good coder is.<p>Because of this effect, our industry is currently in a bad state. Many of the big popular tech stacks are mediocre compared to some of the alternatives that are available. There is a lot of misinformation and misplaced hype.<p>Most people who have the power to make hiring decisions are not sufficiently good at coding to be making those decisions. So good coders tend to find themselves smothered in most work environments...
Please stop thinking there are 10x programmers - or perhaps stop thinking it means 10x <i>better</i>.<p>It is simply 10x more <i>valuable</i>. And that depends on the organisation you work for, the state of the code base and so on.<p>Look at it this way - sports stars are regularly 10x, 100x more <i>valuable</i> to their team management than A.N.Other professional player. Take football (soccer) - Ronaldo is a waaaay better player than I am easily 100x, but take the newest signing in league 3 or whatever it is - can Ronaldo run 10x as much, is he 10x as likely to put in a penalty or a free kick? No. it's probably not even a question of twice as likely - it's percentages better.<p>It's just that those percentages <i>matter</i> when the cup is on the line. I am sure that Baseball statistics probably show this - the spread from top of the league to bottom is unlikely to be 10x more runs scored<p>So more and more it's worth remembering that the value provided to an organisation (and remember that's what you can charge for) is based not on your intrinsic qualities but what you can do for them in their current state.
> Three years later, I am still very much the apprentice.<p>Well, three years is really not a lot when it comes to developing an intuition. Just enough to grasp some basics.<p>> a writer is someone for whom writing is more difficult than it is for other people<p>Yeah, I seem to recall Douglas Adams saying that the easier it is to read a text, the harder it was to write it.<p>At the beginning of my career I was constantly being praised for how fast I work. Well, I did stuff that worked, the effects were quickly visible, everyone was happy.<p>Even though there were code reviews to weed out the ugliest stuff, I wouldn't want to go back and maintain that software today :P
I use one rule: If it's easy to remove, then it's fine.<p>Because only then, i don't fear refactoring later.<p>So i'll get my goal: Easy refactoring for fun and profit.<p>Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.
It's very easy: most coders are undisciplined hackers, not engineers. Unfortunately the prevalent macho coder culture (agile, and the rest of that crap along the lines of "move fast break things") positively encourages hacking away without much planning, design, or forethought.<p>Real engineers spend most of their time learning, thinking, designing, and planning. Coding for them is mostly exercise for fingers, something which needs to be done but ultimately providing no challenge. They learned not only from textbooks but also from their own mistakes, and know what to watch for and where to double-check themselves.<p>The outcomes are strikingly different: code produced by real engineers usually simply works. No need to babysit it in production. It also solves the real problem rather than "improving" on something which was adequate in the first place (face it: most new software replacing the older one is worse - more bloat, more bugs, harder to use). The real engineer understands that complexity is THE enemy, and breeding (or dragging in) unnecessary complexity is a hallmark of a freaking amateur.<p>Oh, and academia doesn't teach engineering. Your C.S. degree means shit. Old codgers who remember punching cards and incantations like //GO.SYSIN DD * may be tired of learning the shiny new toys and aren't up to the speed on the latest jargon, but over the years of wrangling code they acquired wisdom, and you'd be very well advised to listen to them.
I've had this conversation a million times. I think when you're learning and working on your own to build a skill, do it fast and do it over and over. When you're working on a shared code base, you need to be more cognizant of your actions, of maintaining the established styles and conventions. I've know very few 10x or 100x programmers, and am not one myself. But I have had to deal with people who sacrificed quality for speed and every time a code review for those kind of people comes my way, I know I'm in for a ride that will take me away from the work I need to be doing.
> Three years later, I am still very much the apprentice.<p>I used to think I’d get to the point where I could just sit down and breathe out perfect code, but that doesn’t happen. As I’ve thought about the reasons why, I came up with the following reasons:<p>1. Writing code is an act of inventing. If what I’m trying to build already existed, I could just go buy it and save myself a lot of time and money. It doesn’t exist though. I’m being paid to create something new and unique. This requires thought, trial and error, and multiple iterations to get right.<p>2. The software development landscape is not a static one. I used to build commercial buildings with my dad. Once I learned that studs should be set at 16” on center, how to measure and cut complex angles, and how to finish cement, I never had to learn those things again. They were pretty much static and I got to where I <i>could</i> breathe out a plumbed wall without thinking about it. In the software industry, developers are constantly having to learn new things. New languages become popular, companies jump on things like Kubernetes because everyone else is, the JavaScript community cranks out new libraries and frameworks on almost a daily basis. While the fundamentals of recursion, looping, and conditionals remain the same, the syntax, idioms, and best practices are constantly shifting. After 30 years of programming, I don’t think I’ll ever stop being an apprentice in at least some aspects of my career.
I do not believe the ceramics story. It is either nice fake to prove the point or what that particular teacher valued was a natural expression rather than perfection. Applying that principle to photography would mean that every one of us is now an artist because we made 1000s of vacation photos and photographers that used just film cameras are bound to produce lower quality work. I've also seen many startups that generated a lot of low-quality code that became a tech debt super fast, and all it needed is someone stopping the line and rethinking the whole thing.
I suspect there may be better ways to practice, rather than just doing it more? Some people put effort into memorization of commonly used idioms.<p>Here's another dubious analogy: when learning music, you do need to practice, but playing a song all the way through a bunch of times is a rather inefficient way to practice it.
I'm surprised the author didn't mention <i>learning</i> about programming. Programming did come out of the field of computer science, after all.<p>Not that I think one should never do any hands on practice, but if you spend a large chunk of time learning the concepts of different mathematical fields related to programming, as well as the teaching of other programmers, you'll become a much better programmer than you ever could otherwise.
I really disagree with this. There's a point on most projects where you've learned about all you're going to learn from it. Maybe it's still growing, but it might not be teaching you anything new. The best way to get good is diversity of experience, and the best way to get diversity of experience is to do a lot of different things. The more diversity you can pack into a smaller time space (without just cramming and rushing things), the faster you'll get good.<p>If you've only been programming 3 years, you're definitely going to make a lot of mistakes. That's good! That means you're pushing your boundaries and learning. Peer review feedback isn't a mark of shame; and being attached to your code is a _bad_ thing. At the end of the day, coders vastly overvalue code beauty and aesthetics, and overestimate how long their code is really going to live. (I've been a professional for about 11 years, and while I take pride in my work, a lot of the companies I worked for either folded, pivoted to a new product, replaced some of the things I wrote with open source solutions after the problem space had become less novel and a proprietary solution didn't make sense anymore, or a billion other reasons why the code didn't need to live anymore. I'm not saying that's an excuse to write shabby code, but a lot of times "it works and it solves the problem at hand and the code isn't a disaster" is when you should stop working on it).<p>I think coding is a lot more like creative writing than it is like engineering, and if you want to get good at creative writing you make a point of writing a lot of stories, even though a lot of them won't be good. Or if you're composing music, you write a lot of music, you don't focus on one piece forever. Anything where you make, the more you make, the quicker you get better at it.
I think we’re conflating learning and producing when we discuss quantity and quality. During learning time, quantity is what you want to focus on. During work mode, you want to slow down and think carefully. Only when you are very sure about the selected solution that you start going quickly. Applying the story of James Joyce in a broad stroke might be misguided.<p>If I have to pick, I’d err on the side of doing more than trying to slow down and write perfect code. When you’re junior, your definition of “perfect” code might be very different from others’. You might be reinforcing bad habits rather than learning. I’ve seen junior SWEs insist on spending hours eliminating a couple lines of duplicated code by pulling them out into functions to achieve their perfect code. At the same time, they neglect basic coding hygiene, put defensive nullptr checks everywhere, and not design for readability and testing.
The author has another blog post about learning to play the violin and how it taught him the importance of deliberate practice which I feel is probably what he is also trying to get across in this post.<p>I am experiencing something similar as I continue to study the classical guitar.<p>I agree that the importance of deliberate practice over just coding and coding really does matter - in my day job I will write many lines of code doing the same string processing etc. (I work in Data Science) but when I am trying to learn I really want to think if I am doing it in a Pythonic way, how I might make the code more reusable and so on.
I spent my first 4 years after the university at a company with very little quality control. We had to talk the bosses into having code reviews. When we began having code reviews my older colleagues never complained about anything - everything went through.<p>That truly was quantity over quality. Oftentimes I had to wade through piece-of-shit code that really made my soul hurt. Really. Bad.<p>But in hindsight that was good. It's good to have spent 4 years ONLY writing code 8 hours straight 5 days a week.<p>But I never, ever, want to go back to anything like that.
>> The best writers write much more slowly than everyone else, and the better they are, the slower they write.<p>By that metric George R.R. Martin is on track to be the greatest writer of all the time :)
For me the best analogy is a carpenter tightening screws. When you start out solving a particular problem part of the scope and required functionality is always not 100% clear. So you start out with an implementation which favors flexibility over things such as DRY or performant. As you learn more about the problem you start to optimize.<p>One of the biggest mistakes (the biggest one is probably not writing tests) I see junior engineers make is trying to optimize before fully understanding the required functionality.
I'm surprised the author's takeaway from the Joyce quote was disillusionment. He's actually quite close to the secret sauce. I don't think writing more code and ending up with less code are at odds. In fact, I think you need to write more code to end up with less. You write more code in order to understand the problem space. Once you understand the problem space, you can then refactor everything that you wrote into more concise code that more accurately reflects the problem.<p>James Joyce wrote Ulysses at the rate of a hundred words per day if you only consider the finished product. However, I doubt every word that Joyce wrote ended up in Ulysses. I'm sure he did quite a lot of cutting and rewriting.<p>The takeaway from me from the two quoted stories was that quality and quantity are not at odds, but instead are the yin and yang of productivity. They reinforce each other. The more things you produce, the more patterns you are exposed to which in turn leads to higher quality since experience leads to efficiency, giving you more time to get things right.
I think when you are starting some new concept, that you are learning as you go you need to just try to do your best of throwing stuff on the wall to get it to work, refactor a lot and keep grinding away. During this time you are building the "Big picture" of what it is.<p>Once you get a good enough big picture then you probably will start to realize where how to optimize the data and create better methods, but even there it still never stops, you now know the system, and can figure out what you need from the technology to construct a better platform.<p>The databases I've worked with for over 20 years have evolved as I have added more functionality, I have been able to identify where the priorities were as well as how to make it function more dynamically. I didn't really get the big picture for a decade as they were sill doing part of it analog and only requested (revealed to me) more functionality as the system grew more capable.<p>You may think you know it all now, but I would think there's still a lot more road to be covered after only three years.
As one of the million people who tried to read Ulysses and failed, I'm not sure I'd hold up Joyce as the example of what programmers should aspire to. There's plenty of popular and even good creative works which were written quickly or even under external time pressure.
This article is good, but these conversations here on HN always bug me.<p>Yes—write a ton of code.[0] Just do it. Make your favourite couple languages extensions of yourself.<p>Yes—think through your code really clearly. Spend a day on your migration or other data-structure altering changes. They're going to echo throughout your whole application and, ultimately, organization.<p>[0] The closer you get to the API, the faster you should code. Not the interface definition itself, that should be thought through, but the code that responds to a call to the interface. The serializer, the part of the controller that calls the render, these parts are easy. Just roll them out. The models and migrations are much more important. Spend time there. It's not an all or nothing thing.
I've been facing this in the past year after I started doubling my consulting rates. A part of me wanted to do 2x better work as well, and that just ended up in getting less work and lower quality work done.<p>Taking my sweet time is definitely not productive either.<p>I find the balance is to treat it like sketching. Instead of trying to "print" out code, well designed from scratch, from top to bottom. It's better to sketch out the main "lines" of it. It involves a lot of erasing past lines and old code, or even making redundant code at times. You definitely need a lot of scaffolding and placeholders, especially early on.
This is why programming (as a profession) is engineering and is different computer science (as it is today -- when I was a student 40 years ago it was still turning into a "science"). Engineering as a discipline is at its heart balancing tradeoffs of factors like time, cost, weight, strength, efficiency etc. There is no single pole on any of these axes that can dominate, even though for illustrative purposes it's generally useful to do so when writing an essay.<p>(Also three years is a really short time, though the author seems to be using that time well in order to learn and meta-learn).
> “Refactoring code” would be something left to the apprentice, not something that I, the master who has churned out enough ceramic pots, would be bothered with.<p>The master potter does not churn out pots that need to be fixed. He focuses on quantity to get to quality faster, that is the whole point of that story in my opinion.<p>Also, "refactoring code" should not be seen as such a separate activity that it can (or should) be done by other people.
The point as applies to individuals extends to projects also:<p><i>> Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.</i><p><i>> [...] plan to throw one away; you will, anyhow.</i><p>Fred Brooks, The Mythical Man-Month (1975)
People used to heavily criticise Minecraft from a technical point of view. Their criticisms were often entirely reasonable - it was at one point a very inefficient and unstable piece of software. However, it's now the second best-selling game of all time. Sometimes it's better to churn out a release and fix the problems later than let quality worries block you from achieving anything.
Interesting. I've "evolved" in exactly the opposite way. I used to go for quality all the time. Nowadays I'm pretty confident getting things done swiftly (and thus enabling more code/design iterations) works better for me in both the short and the long term.<p>That being said, I definitely don't pretend to be the Thomas Mann of software engineering.
Doing it more can provide better result <i>only</i> when it is allowed to trash the previous iterations to use the latest one.<p>This is <i>not</i> the case in the industry, we <i>cannot</i> change everything in a product at each iteration. This is why at least a little care and architecture have to be done before doing it and trashing must be made with care.
This is why there are so many vulnerable products in the market and engineers are tired of fixing them.
People do not think before they start and they are confident enough to say that they have learned from their faults when they are actually too tired to complete the fixing process.
One prolific programmer who comes to mind from this article is Nikolay Kim, author of the Actix projects in Rust, aiohttp in Python, and many other open source projects. The Actix Project has evolved so much over a short period of time. The author learns by doing, with haste.
Part of me feels like bootcamps are effective for some because you will inevitably start getting it when you do it for 15+ hours a day every day for an extended period of time (which is more than you’d likely do on the job or in a more theoretical CS degree)
Write more, care about your craft in general terms. Then it'll get better. It's a skill, skills get better with more practice. Premature optimization is the root of all evil.
I think that being a professional is exactly that:<p>"Being able to balance those two core things to meet client needs."<p>Any kind of extremisms is bad, no matter where applied.
People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days.<p>How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan <i>what</i> to implement, do it, then improve it when it's done; inspiration comes from working on something, not from thinking about it) and never even meet their own estimates for how long it'll take them to deliver. They will tell you they are taking so long because they haven't decided yet how to best implement something, but they don't even have a straightforward implementation (there's always one). If they were truly concerned with "the best way", they'd have several solutions implemented already, together with metrics and benchmarks. They haven't, because they're vain impostors and not capable programmers.
Programming is simple. Domains and interfaces are difficult. People over engineer stuff. People like to think they found the key to hidden wisdom. I believe I just summed up 90% of the difficulty with programming.<p>Just for the record procedural programming and functional programming are the only two styles of programming to me that make sense. Procedural because its how the machine model works and functional because its how a mathematical description of computation works. WTF is OOP (how the over active imagination of a child works I would reckon).