7 ms·

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 p

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

rvanmil 8y ago
I think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.
- varjag 8y ago
  Take a "perfectionist", and you end up having all that atop of nothing actually yet running in production.
- lazyjones 8y ago
  Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really overrated. I left a huge pile of it in my previous company (amassed over 18 years of programming in Perl) and guess what: it's doing great, more profitable than ever before. The code has been slowly enhanced, some of it refactored. Code quality (as in "beauty", not correctness) is the least of your problems in a startup, although it will look bigger for those who have to work on it (pity them but don't overemphasize).
  - Ma8ee 8y ago
    Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost. I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.
    - lazyjones 8y ago
      > When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. Kinda obvious what their actual mistake was then... > I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. I see a pattern there. > But of course you also have to be able to be nimble and move fast even after two years and five. You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase. I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.
      - Ma8ee 8y ago
        I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess. Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.
- scarejunba 8y ago
  It actually doesn't matter because you can always rewrite a working product. If you never have a product nothing helps. In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.
  - extra_rice 8y ago
    > It actually doesn't matter because you can always rewrite a working product. False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.
- soup10 8y ago
  In my 20 years of programming i've never heard of a well architectured codebase that is cleanly written, problem free, future proof and a joy to maintain.
  - arethuza 8y ago
    I've heard of plenty (mostly in the future tense) - reality often seems somewhat different.
  - collyw 8y ago
    Sure, but some codebases are way worse than others.
  - adamlett 8y ago
    Lots of open source projects are well architected and cleanly written[1]. Demanding that they also be problem free, or future proof, is a red herring. I've never heard any proponent of clean code claim that these are side effects of clean code. [1] Examples I can think of off the top of my head: KHTML/Webkit, Hanami.rb, the Go standard library, sqlite...
- konamicode 8y ago
  > At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code. Ousterhout uses the term "tactical tornado"s, which I quite like (source: https://twitter.com/johofer/status/1035442341199446017 https://twitter.com/johofer/status/1035442341199446017 apologies I don't have a better source handy).
- mpartel 8y ago
  Moreover, I think there's an 80/20-ish sweet spot. With an attitude of moderation, you can keep a brisk pace and achieve a pretty clean codebase with little extra effort. It seems best to defer architecting just long enough to see that some component is becoming problematic, but not much longer. Do it too early and you waste effort. Do it too late and you have a much larger mess to clean up.
franciscop 8y ago
This, 1000x times. Experience throwing code does a lot in my experience (~7 years programming, 4 professionally). Learn the best practices, and know when they break. Heck, purposely break them and see if/when/how they bite you back! A very good rule of thumb to recognize the former group is to simply ask "when is this best practice not valid"? This will tell me whether they are consciously proposing it or mindlessly adding complexity. For every single "best practice" I can find you a case where it's not valid, and if you cannot then there's something very wrong.
- hhs 8y ago
  Interesting view. In your experience, how did you learn about the best practices - and, then, consider asking when that practice is not valid? It looks like you add purposeful breaks, experiment, and then see what happens. I wonder if you also talk with your colleagues, self-reflect, think about the big picture rather than just the task at hand when you're doing this?
  - franciscop 8y ago
    I started coding for fun because I wanted to build things, so when I had a problem I searched how to fix it. At some point, I started noticing "larger" problems that have to do with code structure and data flows. Since I am self-taught and everyone was talking about "best practices", I started to learn and follow those around 1-2 years into coding. I built beautiful abstract glass houses that didn't get me any closer to my objectives! So I was curious why these best practices were slowing me down and started digging deeper to be able to know how, when and why to apply them. Lots of conflicting info online, so had to start thinking about those by myself and not just follow random articles. I even started searching conflicting info to see the two sides. But yeah, you are totally right, devs get stuck into that pixel and forget about the larger picture. I switched my thinking to a purely "ROI" for the business, and I am convinced it's been a strong win-win. But you have to learn about the real, implicit and explicit, business objective, which is something 99% of devs do not really care (or need to, in this market). I also started realizing how code was many times not taking me closer to my objectives, but that's a topic for another day.
arethuza 8y ago
"inspiration comes from working on something, not from thinking about it" Not sure about that - the applications I'm most proud of actually came from extended periods where I was involved in maintaining an existing system, carefully thinking about how it could be improved, so when a chance came I could propose a new application with a well defined list of benefits. Note that by "extended period" I mean a couple of years!
donquichotte 8y ago
What I really admire is people who manage to do all of it: start projects, finish them, and produce beautiful code that is simple to reason about. Whenever I feel bad, sad or just in need on some enlightenment, I go to https://github.com/fogleman https://github.com/fogleman and browse Michael's repos.
klichtman 8y ago
I agree with most of this, but it is more a matter of talking about programming or being an architecture astronaut. You can still write beautiful code and be productive. OpenBSD contains some examples. Of course, as you say one should not talk about writing beautiful code. Just do it.
- lazyjones 8y ago
  > You can still write beautiful code and be productive. OpenBSD contains some examples. Yes, by all means - if you can, do it. But please try to become as productive as John Carmack first before you aspire to write similarly beautiful code.
momania 8y ago
Adding to that: written code has no value, only running code has. The quality of what running code is, or needs to be, depends on the stage of your product and who will be responsible for keeping the code running (either the developer himself or an ops team for instance).
black-alert 8y ago
> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment. I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not capable? At this very moment I am working on a total rewrite of an unmanageable codebase that was written by a very 'productive' guy.
- Udo 8y ago
  Any paradigm can be formalized to the point of perversion. I think that's what the OP meant when they said that the hallmark of that group is how they obsess about standards and processes. The existence of cowboy-style code such as the project you're currently dealing with does not necessarily mean that the "process-over-results" people are in the right. There are many factors to consider, including the structure of the organization you're writing the code for. I don't think it's naive advice to suggest that people spend less time listening to vain role models, instead of actively working on their own skills in order to make better judgements in the future, which brings us back to the point put forward in the article: the way to mastery is through practice.
- rzwitserloot 8y ago
  I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on. How I take the article, and what I think most in this entire comment thread agree with, are the following principles: [1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base is to requests for additional features/changes, and how easy it is for new hires to grok it / for you to grok it after a few months have passed working on something else and you've lost familiarity. [2] Whilst it is important, it is not the only concern. In fact, a shipping product is MORE important. That's not to say that code quality isn't important. Any project that has deplorable code quality even if it ships is in trouble. [3] So far the most effective strategy for producing code with high quality, is experience (that's subjective; my opinion. But I bet you share it). The best way to get experience is to write lots of code. In fact, writing code of LOW code quality should help MORE: The 8th feature request that comes in that initially sounds like a job of a few hours that turns into a weeklong exercise in frustration with stapled onto the end of that process another week or two chasing bugs - and maybe you learn something about where you went wrong in your code that powered the initial shipping product. This sounds like a much better way to learn these lessons than reading a bunch of blogs and listening to a bunch of presentations theorising about what 'beautiful code' means. [4] extremes are bad. This more or less is already concluded by #1-#3, though. However, the 'beauty' extremists tend to present, blog, and in general act like they hold all the answers, more than the cowboy extremists do. That's entirely subjective opinion, of course. It's just my experience, and yours may well be different. But _IF_ it is indeed true that you're far more likely to run into a beauty extremist than a cowboy extremist, then it stands to reason programmers who are irritated by extremists of any colour will tend to exaggerate somewhat more on the _other side_ of the beauty extremists. In the end it's a pendulum, isn't it? A presentation or blog post that comes across as authored by a beauty extremist probably was a capable, 'well adjusted' (in the sense that they would agree that shipping code is at least as important, and experience is very important) – but decided to exaggerate a tad on the beauty side to address some perceived notion that the audience's balance was too far towards the cowboy end of the spectrum. Enough of those kinds of presentations, and a few are bound to perceive that the pendulum has now swung too far out towards the beauty end, and start exaggerating the value of the cowboy end.
extra_rice 8y ago
Just as bad as the people who obsess over "beautiful code" and whatnot are the people who straight out reject the idea, then label those who observe them the "enemy" of this industry. I think the key here really is mindfulness. Developers read code significantly more than they write them, and one of the primary goals of best practices and clean coding guidelines is to help teams communicate effectively through code. Writing code well is a skill, but that doesn't start and end at taking all the "rules" to heart; that's just the first step. The next is really to recognise that there aren't any rules, but more heuristics based on collective experiences. Software development is not an exact science, and just like the Agile Manifesto, clean coding guidelines only provide framework upon which to build any team's practices: a starting point from which to find what actually works for their project.
remeq 8y ago
I dislike this way of thinking. Programmer shouldn't be described like: ability_to_beautiful_code ---V------------ ability_to_deliver Programmer should be described more like: ability_to_beautiful_code: 0%---V-----------100% ability_to_deliver: 0%----------V----100% And both metrics should have certain threshold for you.
smadurange 8y ago
Write beautiful code, build productive and correct software, live long and prosper :V
lm28469 8y ago
> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line. How many times have I seen developers push some "good enough" code that they didn't discuss with anyone because it looks good to have XXX commits for their quarterly feedback. They knew "what" to implement but not "how" to implement it or even "why" implement it in the first place, which ends up in hours of useless discussions that would have been avoided by a 1hr meeting before starting coding. How many times have I seen people going for a DB, stick with it for years because "that's what google/facebook/whatever uses" and end up having to migrate everything to another DB because they went to fast and didn't spend 1/10th of the time on analysing their needs and writing specs. Do you spend 10 years designing a plane and then 6 months actually building it, or do you spend 6 month planning it and 10 years fixing broken, hacky, "mostly working" parts ? What works for school or hobby projects doesn't work in most professional environments, especially nowadays when developers stays 1-3 years in a company and move to the next job leaving a pile of unmaintainable "mostly working" code. Coding is the last stage of the process, it's the easy part, a monkey could implement the code if the specs and processes are solid. People who want to deliver at all cost are not role models, don't listen to them. They are vain and not productive. They might be capable coders but they're not capable engineers for sure. “Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth
- lazyjones 8y ago
  > People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line. Wildly exaggerated, but I'll bite: it's still better to save 5 hours while you are bleeding money (before your product works) and spend 1 week to improve the "beauty" of your code while it's already paying your salary. > “Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth That's a fine attitude for someone who wants to teach CS or explore programming as a hobby. For professionals, programs need to execute correctly and go into production ASAP. Emotional and mental cost to the programmer is of less importance.
norswap 8y ago
Like everything, it depends. I think you're right for some classes of problems. For others, going slow and painstakingly seeking to simplify is the only way. Otherwise the complexity will eat you alive and the whole edifice will collapse on itself.
fluffycat 8y ago
I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time than you before, even if they seem to be obsessed with "beautiful code".
- cousin_it 8y ago
  Most of the damage I've seen was from people who think they can write beautiful code, but instead write a slow overengineered framework and use clout to force everyone else's code into that framework. Sadly, these people are often smart and experienced. It's more of an attitude problem: they are not content with making a library that will sit at the bottom of the call stack, when they could instead make a framework that sits at the top.
  - JustSomeNobody 8y ago
    I've worked at a couple companies now that have this problem. I know that one is now on their third try at a second gen rewrite of their aging core product. They can't ship it because they haven't found that magic formula to make it the most perfect program ever[0]. Sadly, this has been with multiple teams trying. [0] I call this the Neo Architecture. They're looking for "the one". The architecture that will allow for any CR to be handled elegantly and beautifully, where all concerns are completely separated, where all data is perfectly abstracted. There's no such thing. It doesn't exist. Just ship already!
- lazyjones 8y ago
  > I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code Because people who write "beautiful code" don't often achieve anything that can be seen. Successful companies are based on quickly written code that delivers.
remeq 8y ago
I despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams and presentations but I am an engineer, and I like myself and my life and as a result I just want to do and be surrounded by beautiful things so I honestly don't give a shit if some product will not be delivered on time because product managers did include only business requirements and ignored requirement of my engineering team that we need to be able to sign our name under the code we write and be surrounded be beautiful things in our work life. Sorry, but engineers are part of the team, part of the product, if you ignored that at the beginning, it is not our fault. Also, ability to write beautiful code implies the ability to deliver code much more then vice versa because there is a good chance that someone who actually is capable of writing beautiful code had to get to that level by actually also delivering stuff to production in the past. So yes, in my world, someone who writes a beautiful code (meaning - correct, performant, maintainable, understandable, clever and so on) is a pretty good candidate to be a role model.
- Ntrails 8y ago
  > meaning - correct, performant, maintainable, understandable, clever and so on My favourite part of this is how often these criteria are essentially at odds. - Understandable *and* performant? - Clever *and* maintainable? But, you know, I'm also bad at all this so maybe it's just me :p
  - remeq 8y ago
    Yeah, I didn't really mean everything at once, I just wanted to make clear that "the beautiful" can be disaggregated into some engineering qualities.
    - Ntrails 8y ago
      Yeah, it was more a comment on the natural compromises that come about from trying to be all of the best things in your code. Perfect being enemy of good etc. Agree entirely that they're all things that contribute to "good"
purple_ducks 8y ago
> Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. Generally done by people who don't think through the requirements or know why they're doing what they're doing. "I just copied pasted the example and hacked it until it did what i wanted. I'm still not sure why it works lol" Completely fucking over the next person who has to work that code.
- peteradio 8y ago
  It's the American way! Leave a steaming pile of shit behind and laugh at the next idiot for stepping in it.
- satokema 8y ago
  It would be much easier if the next person were the creator of the code, but instead we have this machine cog mindset of "we can just throw any of our developers at any given problem whenever".
snidane 8y ago
Also known as the difference between doing things right (beautiful code) vs doing the right thing (working software). I like ideas from the systems thinkers like Russell Ackoff about this. > Ackoff expands by suggesting that doing things right is about efficiency but doing the right thing is about effectiveness. He makes a strong case for the connection between wisdom and doing/identifying the right things. He notes further that when we try to do things right about the wrong thing, we actually make things worse. Such attempts at improvement actually take us further from both the recognition and accomplishment of the “right thing”. https://ackoffcenter.blogs.com/ackoff_center_weblog/2018/04/there-is-a-difference-between-doing-things-right-and-doing-the-right-thing.html https://ackoffcenter.blogs.com/ackoff_center_weblog/2018/04/...
swat535 8y ago
The issue here isn't beautiful code vs quick code. I think it's between spending some time and thinking about the problem you are trying to solve vs brute forcing a quick prototype to get it done. I think your code will look beautiful by itself if the engineer fully understands the problem at hand. This process takes time and practice. I personally throw away my quick first solution and let the fog clear first. Somethings that have generally given me good results: drawing stuff, taking small breaks, listening to my tests (if my tests hurt, it means my design is bad) Would love to hear other thoughts on this !
stronglikedan 8y ago
I've "finish[ed] more correct programs on time" by planning all of the details in a Design Document before writing a line of code, than I ever have by planning at a high level only before implementing, but that's just my personal anecdote. Although, I do take the MVP-then-iterate approach if I don't have a tight deadline, because the early feedback loop can be invaluable in that type of development process.
tinus_hn 8y ago
War is peace. Freedom is slavery. Worse is better.

rvanmil 8y ago

I think it’s a balance. At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.

varjag 8y ago
Take a "perfectionist", and you end up having all that atop of nothing actually yet running in production.
lazyjones 8y ago
Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really overrated. I left a huge pile of it in my previous company (amassed over 18 years of programming in Perl) and guess what: it's doing great, more profitable than ever before. The code has been slowly enhanced, some of it refactored. Code quality (as in "beauty", not correctness) is the least of your problems in a startup, although it will look bigger for those who have to work on it (pity them but don't overemphasize).
- Ma8ee 8y ago
  Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost. I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.
  - lazyjones 8y ago
    > When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered. Kinda obvious what their actual mistake was then... > I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours. I see a pattern there. > But of course you also have to be able to be nimble and move fast even after two years and five. You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase. I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.
    - Ma8ee 8y ago
      I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess. Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.
scarejunba 8y ago
It actually doesn't matter because you can always rewrite a working product. If you never have a product nothing helps. In the end, all code is debt. The only thing is whether you earned anything from the debt. If you never earn anything it doesn't matter that you didn't take on that much debt.
- extra_rice 8y ago
  > It actually doesn't matter because you can always rewrite a working product. False. Sure, technically, this is true, but in practice there are lots of variables at play here. Who is going to pay for the rewrite? Is the company profitable enough to do that while maintaining legacy code for current users to use? I'm not saying the only way to develop a product is to get it right the first time, but ideally, organisations shouldn't have to pay for the same product twice.
soup10 8y ago
In my 20 years of programming i've never heard of a well architectured codebase that is cleanly written, problem free, future proof and a joy to maintain.
- arethuza 8y ago
  I've heard of plenty (mostly in the future tense) - reality often seems somewhat different.
- collyw 8y ago
  Sure, but some codebases are way worse than others.
- adamlett 8y ago
  Lots of open source projects are well architected and cleanly written[1]. Demanding that they also be problem free, or future proof, is a red herring. I've never heard any proponent of clean code claim that these are side effects of clean code. [1] Examples I can think of off the top of my head: KHTML/Webkit, Hanami.rb, the Go standard library, sqlite...
konamicode 8y ago
> At the other end of the spectrum are the “cowboys” who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code. Ousterhout uses the term "tactical tornado"s, which I quite like (source: https://twitter.com/johofer/status/1035442341199446017 https://twitter.com/johofer/status/1035442341199446017 apologies I don't have a better source handy).
mpartel 8y ago
Moreover, I think there's an 80/20-ish sweet spot. With an attitude of moderation, you can keep a brisk pace and achieve a pretty clean codebase with little extra effort. It seems best to defer architecting just long enough to see that some component is becoming problematic, but not much longer. Do it too early and you waste effort. Do it too late and you have a much larger mess to clean up.

franciscop 8y ago

This, 1000x times. Experience throwing code does a lot in my experience (~7 years programming, 4 professionally). Learn the best practices, and know when they break. Heck, purposely break them and see if/when/how they bite you back! A very good rule of thumb to recognize the former group is to simply ask "when is this best practice not valid"? This will tell me whether they are consciously proposing it or mindlessly adding complexity. For every single "best practice" I can find you a case where it's not valid, and if you cannot then there's something very wrong.

hhs 8y ago
Interesting view. In your experience, how did you learn about the best practices - and, then, consider asking when that practice is not valid? It looks like you add purposeful breaks, experiment, and then see what happens. I wonder if you also talk with your colleagues, self-reflect, think about the big picture rather than just the task at hand when you're doing this?
- franciscop 8y ago
  I started coding for fun because I wanted to build things, so when I had a problem I searched how to fix it. At some point, I started noticing "larger" problems that have to do with code structure and data flows. Since I am self-taught and everyone was talking about "best practices", I started to learn and follow those around 1-2 years into coding. I built beautiful abstract glass houses that didn't get me any closer to my objectives! So I was curious why these best practices were slowing me down and started digging deeper to be able to know how, when and why to apply them. Lots of conflicting info online, so had to start thinking about those by myself and not just follow random articles. I even started searching conflicting info to see the two sides. But yeah, you are totally right, devs get stuck into that pixel and forget about the larger picture. I switched my thinking to a purely "ROI" for the business, and I am convinced it's been a strong win-win. But you have to learn about the real, implicit and explicit, business objective, which is something 99% of devs do not really care (or need to, in this market). I also started realizing how code was many times not taking me closer to my objectives, but that's a topic for another day.

arethuza 8y ago

"inspiration comes from working on something, not from thinking about it" Not sure about that - the applications I'm most proud of actually came from extended periods where I was involved in maintaining an existing system, carefully thinking about how it could be improved, so when a chance came I could propose a new application with a well defined list of benefits. Note that by "extended period" I mean a couple of years!

donquichotte 8y ago

What I really admire is people who manage to do all of it: start projects, finish them, and produce beautiful code that is simple to reason about. Whenever I feel bad, sad or just in need on some enlightenment, I go to https://github.com/fogleman https://github.com/fogleman and browse Michael's repos.

klichtman 8y ago

I agree with most of this, but it is more a matter of talking about programming or being an architecture astronaut. You can still write beautiful code and be productive. OpenBSD contains some examples. Of course, as you say one should not talk about writing beautiful code. Just do it.

lazyjones 8y ago
> You can still write beautiful code and be productive. OpenBSD contains some examples. Yes, by all means - if you can, do it. But please try to become as productive as John Carmack first before you aspire to write similarly beautiful code.

momania 8y ago

Adding to that: written code has no value, only running code has. The quality of what running code is, or needs to be, depends on the stage of your product and who will be responsible for keeping the code running (either the developer himself or an ops team for instance).

black-alert 8y ago

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Your thoughts seem to be very subjective. I hope you don't write your code as naive as you wrote this comment. I code for over 30 years now. It has always been my desire to write beautiful code that reads well, scales well, has no bugs and performs good. Does this makes me a vain imposter and not capable? At this very moment I am working on a total rewrite of an unmanageable codebase that was written by a very 'productive' guy.

Udo 8y ago
Any paradigm can be formalized to the point of perversion. I think that's what the OP meant when they said that the hallmark of that group is how they obsess about standards and processes. The existence of cowboy-style code such as the project you're currently dealing with does not necessarily mean that the "process-over-results" people are in the right. There are many factors to consider, including the structure of the organization you're writing the code for. I don't think it's naive advice to suggest that people spend less time listening to vain role models, instead of actively working on their own skills in order to make better judgements in the future, which brings us back to the point put forward in the article: the way to mastery is through practice.
rzwitserloot 8y ago
I think you and the person you're replying to are closer in opinion about what it means to write good, professional code, then your comments are letting on. How I take the article, and what I think most in this entire comment thread agree with, are the following principles: [1] code quality IS important. I define 'code quality' here as how many bugs are introduced to do a given feature, how resilient this code base is to requests for additional features/changes, and how easy it is for new hires to grok it / for you to grok it after a few months have passed working on something else and you've lost familiarity. [2] Whilst it is important, it is not the only concern. In fact, a shipping product is MORE important. That's not to say that code quality isn't important. Any project that has deplorable code quality even if it ships is in trouble. [3] So far the most effective strategy for producing code with high quality, is experience (that's subjective; my opinion. But I bet you share it). The best way to get experience is to write lots of code. In fact, writing code of LOW code quality should help MORE: The 8th feature request that comes in that initially sounds like a job of a few hours that turns into a weeklong exercise in frustration with stapled onto the end of that process another week or two chasing bugs - and maybe you learn something about where you went wrong in your code that powered the initial shipping product. This sounds like a much better way to learn these lessons than reading a bunch of blogs and listening to a bunch of presentations theorising about what 'beautiful code' means. [4] extremes are bad. This more or less is already concluded by #1-#3, though. However, the 'beauty' extremists tend to present, blog, and in general act like they hold all the answers, more than the cowboy extremists do. That's entirely subjective opinion, of course. It's just my experience, and yours may well be different. But _IF_ it is indeed true that you're far more likely to run into a beauty extremist than a cowboy extremist, then it stands to reason programmers who are irritated by extremists of any colour will tend to exaggerate somewhat more on the _other side_ of the beauty extremists. In the end it's a pendulum, isn't it? A presentation or blog post that comes across as authored by a beauty extremist probably was a capable, 'well adjusted' (in the sense that they would agree that shipping code is at least as important, and experience is very important) – but decided to exaggerate a tad on the beauty side to address some perceived notion that the audience's balance was too far towards the cowboy end of the spectrum. Enough of those kinds of presentations, and a few are bound to perceive that the pendulum has now swung too far out towards the beauty end, and start exaggerating the value of the cowboy end.

extra_rice 8y ago

Just as bad as the people who obsess over "beautiful code" and whatnot are the people who straight out reject the idea, then label those who observe them the "enemy" of this industry. I think the key here really is mindfulness. Developers read code significantly more than they write them, and one of the primary goals of best practices and clean coding guidelines is to help teams communicate effectively through code. Writing code well is a skill, but that doesn't start and end at taking all the "rules" to heart; that's just the first step. The next is really to recognise that there aren't any rules, but more heuristics based on collective experiences. Software development is not an exact science, and just like the Agile Manifesto, clean coding guidelines only provide framework upon which to build any team's practices: a starting point from which to find what actually works for their project.

remeq 8y ago

I dislike this way of thinking. Programmer shouldn't be described like: ability_to_beautiful_code ---V------------ ability_to_deliver Programmer should be described more like: ability_to_beautiful_code: 0%---V-----------100% ability_to_deliver: 0%----------V----100% And both metrics should have certain threshold for you.

smadurange 8y ago

Write beautiful code, build productive and correct software, live long and prosper :V

lm28469 8y ago

> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line. How many times have I seen developers push some "good enough" code that they didn't discuss with anyone because it looks good to have XXX commits for their quarterly feedback. They knew "what" to implement but not "how" to implement it or even "why" implement it in the first place, which ends up in hours of useless discussions that would have been avoided by a 1hr meeting before starting coding. How many times have I seen people going for a DB, stick with it for years because "that's what google/facebook/whatever uses" and end up having to migrate everything to another DB because they went to fast and didn't spend 1/10th of the time on analysing their needs and writing specs. Do you spend 10 years designing a plane and then 6 months actually building it, or do you spend 6 month planning it and 10 years fixing broken, hacky, "mostly working" parts ? What works for school or hobby projects doesn't work in most professional environments, especially nowadays when developers stays 1-3 years in a company and move to the next job leaving a pile of unmaintainable "mostly working" code. Coding is the last stage of the process, it's the easy part, a monkey could implement the code if the specs and processes are solid. People who want to deliver at all cost are not role models, don't listen to them. They are vain and not productive. They might be capable coders but they're not capable engineers for sure. “Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth

lazyjones 8y ago
> People who push "mostly working" code are hell on earth. Sure you spend 5 hours less on it right now, but it's going to cost literal days or weeks down the line. Wildly exaggerated, but I'll bite: it's still better to save 5 hours while you are bleeding money (before your product works) and spend 1 week to improve the "beauty" of your code while it's already paying your salary. > “Programs are meant to be read by humans and only incidentally for computers to execute.” ― Donald Knuth That's a fine attitude for someone who wants to teach CS or explore programming as a hobby. For professionals, programs need to execute correctly and go into production ASAP. Emotional and mental cost to the programmer is of less importance.

norswap 8y ago

Like everything, it depends. I think you're right for some classes of problems. For others, going slow and painstakingly seeking to simplify is the only way. Otherwise the complexity will eat you alive and the whole edifice will collapse on itself.

fluffycat 8y ago

I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code. I understand that fixation to produce something beautiful can lead to paralysis but this is rarely the case. In most cases the prototype grows cancerously and it becomes impossible to fix in quite short time, my advice, listen to the experienced programmers who screwed up more time than you before, even if they seem to be obsessed with "beautiful code".

cousin_it 8y ago
Most of the damage I've seen was from people who think they can write beautiful code, but instead write a slow overengineered framework and use clout to force everyone else's code into that framework. Sadly, these people are often smart and experienced. It's more of an attitude problem: they are not content with making a library that will sit at the bottom of the call stack, when they could instead make a framework that sits at the top.
- JustSomeNobody 8y ago
  I've worked at a couple companies now that have this problem. I know that one is now on their third try at a second gen rewrite of their aging core product. They can't ship it because they haven't found that magic formula to make it the most perfect program ever[0]. Sadly, this has been with multiple teams trying. [0] I call this the Neo Architecture. They're looking for "the one". The architecture that will allow for any CR to be handled elegantly and beautifully, where all concerns are completely separated, where all data is perfectly abstracted. There's no such thing. It doesn't exist. Just ship already!
lazyjones 8y ago
> I have seen way more damage done by the people "mostly working prototypes in hours or days" than people who want to write beautiful code Because people who write "beautiful code" don't often achieve anything that can be seen. Successful companies are based on quickly written code that delivers.

remeq 8y ago

I despise this kind of mentality which tries to demonize someone's passion to actually write a beautiful code. This kind of mentality takes away "the human factor" from the working environments turning IT jobs into delivery driven factories. I for one need to enjoy my work to actually be productive. And don't get me wrong - I understand that product people need to deliver products and they enjoy doing their diagrams and presentations but I am an engineer, and I like myself and my life and as a result I just want to do and be surrounded by beautiful things so I honestly don't give a shit if some product will not be delivered on time because product managers did include only business requirements and ignored requirement of my engineering team that we need to be able to sign our name under the code we write and be surrounded be beautiful things in our work life. Sorry, but engineers are part of the team, part of the product, if you ignored that at the beginning, it is not our fault. Also, ability to write beautiful code implies the ability to deliver code much more then vice versa because there is a good chance that someone who actually is capable of writing beautiful code had to get to that level by actually also delivering stuff to production in the past. So yes, in my world, someone who writes a beautiful code (meaning - correct, performant, maintainable, understandable, clever and so on) is a pretty good candidate to be a role model.

Ntrails 8y ago
> meaning - correct, performant, maintainable, understandable, clever and so on My favourite part of this is how often these criteria are essentially at odds. - Understandable *and* performant? - Clever *and* maintainable? But, you know, I'm also bad at all this so maybe it's just me :p
- remeq 8y ago
  Yeah, I didn't really mean everything at once, I just wanted to make clear that "the beautiful" can be disaggregated into some engineering qualities.
  - Ntrails 8y ago
    Yeah, it was more a comment on the natural compromises that come about from trying to be all of the best things in your code. Perfect being enemy of good etc. Agree entirely that they're all things that contribute to "good"

purple_ducks 8y ago

> Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days. Generally done by people who don't think through the requirements or know why they're doing what they're doing. "I just copied pasted the example and hacked it until it did what i wanted. I'm still not sure why it works lol" Completely fucking over the next person who has to work that code.

peteradio 8y ago
It's the American way! Leave a steaming pile of shit behind and laugh at the next idiot for stepping in it.
satokema 8y ago
It would be much easier if the next person were the creator of the code, but instead we have this machine cog mindset of "we can just throw any of our developers at any given problem whenever".

snidane 8y ago

Also known as the difference between doing things right (beautiful code) vs doing the right thing (working software). I like ideas from the systems thinkers like Russell Ackoff about this. > Ackoff expands by suggesting that doing things right is about efficiency but doing the right thing is about effectiveness. He makes a strong case for the connection between wisdom and doing/identifying the right things. He notes further that when we try to do things right about the wrong thing, we actually make things worse. Such attempts at improvement actually take us further from both the recognition and accomplishment of the “right thing”. https://ackoffcenter.blogs.com/ackoff_center_weblog/2018/04/there-is-a-difference-between-doing-things-right-and-doing-the-right-thing.html https://ackoffcenter.blogs.com/ackoff_center_weblog/2018/04/...

swat535 8y ago

The issue here isn't beautiful code vs quick code. I think it's between spending some time and thinking about the problem you are trying to solve vs brute forcing a quick prototype to get it done. I think your code will look beautiful by itself if the engineer fully understands the problem at hand. This process takes time and practice. I personally throw away my quick first solution and let the fog clear first. Somethings that have generally given me good results: drawing stuff, taking small breaks, listening to my tests (if my tests hurt, it means my design is bad) Would love to hear other thoughts on this !

stronglikedan 8y ago

I've "finish[ed] more correct programs on time" by planning all of the details in a Design Document before writing a line of code, than I ever have by planning at a high level only before implementing, but that's just my personal anecdote. Although, I do take the MVP-then-iterate approach if I don't have a tight deadline, because the early feedback loop can be invaluable in that type of development process.

tinus_hn 8y ago

War is peace. Freedom is slavery. Worse is better.