9 ms·

So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice B

So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well versed in C,C++,PHP,Go,TypeScript and to a lesser degree Java and a few bits and bobs in between F#,Haskell,LISP... The above is not to brag (not that it's brag worthy after 25 years you bound to pick up a few tools) just to put it in perspective. On Code quality: I've noticed it's easy to agree/identify the "extreme cases" the VERY VERY BAD CODING and the very very GOOD CODING. But most of the coders and codebases falls somewhere in between where the code-quality-water quickly gets murky. PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents. The best thus far advise I've seen on code-quality guidelines is from a comment on HN: >I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. Source: https://news.ycombinator.com/item?id=11042400 https://news.ycombinator.com/item?id=11042400 Sure I might just be a dumb idiot or completely not gifted in the "art or science" of coding. :)

stavros 5y ago
Does e.g. Fabrice Bellard code "correctly"? Getting shit done isn't the same as "coding correctly" (sometimes it's very close to the opposite).
- rawoke083600 5y ago
  True - who can say ? Hard to argue with a WHOLE career that got "shit done" and WIDELY used by the world ? Maybe THAT is the metric to focus on. The value of the code versus the quality ? I honestly don't know the answer ? But I know how much of my "time and energy (as you get older you released the limiting step is your cognitive-energy not so much your actual wallclock-time) " I spent on "trying" todo code correctly which many times it means, the code doesn't get done and I end up frustrated by not shipping anything. Working for a boss, the above used to upset me a bit. Now working for myself this REALLY upsets me and my 'income' :) In these cases, I would DEF liked to have "Fabrice" getting shit-done-coding ability ? Again just my humble opinion :) Maybe coding is like a marriage... a) "You can be right or you can be happy :)" Squinting hard enough: b) "You can do things correctly or you can ship code in time that makes a difference ?" I guess the "better" you are the closer the extremes are from "b". i.e IF you are the theoretical-best-coder-that-ever-lived there is should be no "distance/friction" between "coding correctly AND shipping on time code that has an impact" ??
- hinkley 5y ago
  When I was young I wrote code so I could understand it. Everyone goes faster when the code looks like how they expect it to look. Some of these 10x people are really good, others have mental models that are alien, and so nobody else can touch their stuff because none of it makes a lick of sense to anybody else. These are 3x devs that make everyone else .3x devs. Writing code for me made me indispensable, then it made me a bottleneck with a stream of uncomfortable distractions in the form of people queuing up for me to answer questions or fix bugs or implement features. It was exhausting, but I was happy enough. That is, until there was a cooler project I wasn’t allowed to transfer to because I was indispensable. Figure out how to write code so other people can read it. Figure out how to write code so other people can modify it. It looks a bit like clean code, but sometimes isn’t. Occasionally it can be quite different.
asimpletune 5y ago
I love your story. Also: > >I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. That's beautiful advice. Something similar that I heard was "flow of data > dependencies > interfaces", in terms of what to worry about. Interesting how they're so similar but from different sources. But yeah, I second your experiences. Focusing on this stuff, like in code reviews for example, ends up making all other downstream concerns so much easier.
- rawoke083600 5y ago
  >That's beautiful advice. Something similar that I heard was "flow of data > dependencies > interfaces", in terms of what to worry about. Interesting how they're so similar but from different sources. Maybe that is clue they/we are on the right track ? Coming to the similar conclusion from different angles ? :)
bojan 5y ago
> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents. This is a generally good idea, but in small teams it can't really work. Code is in that sense a bit like handwriting, everyone has their own style, and after a long enough time in a small team you learn to recognize whose the author of the code just by reading it.
- skohan 5y ago
  My biggest problem with code reviews is that they are so often without value. Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. In my experience, a lot of the time code reviews are either just a task - where people try to find superficial "mistakes" just to tick a box, or worse a chance for certain colleagues to power trip and try to get other team members to submit for it's own sake.
  - zoomablemind 5y ago
    > ... Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. IMO a practical benefit of a routine code review is just a shared understanding. As simple as that. Does the code look to be doing what it says it should do? Do the tests express the intended behavior? Of course, the style, the quality of code could be of attention too, but that's extras, in my opinion, as long as the functionality is understood and confirmed. I like relating this to an effort of understanding someone who speaks with an accent, be it a local dialect or foreign-originated. It does require some tolerance, but the shared understanding is the goal.
  - muttled 5y ago
    > where people try to find superficial "mistakes" just to tick a box I've found this to be true in change control as well as any meeting involving people who feel they are compelled to "contribute" even if they don't have anything of value. You don't want to seem like the person who's just attending the meeting and slacking off, so if you're expected to contribute and you can't find any useful critiques, you just pick nits.
skohan 5y ago
The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines. After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have. In my experience, over time this approach leaves you with a very ergonomic and easy to understand codebase.
- bncy 5y ago
  I always felt bad for doing things "the pragmatic way", but your comment made me realize that maybe I'm just not experienced enough to embrace the fact that no code is pretty from the start. Thanks!
  - skohan 5y ago
    Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written, vs what your code does? Given that, where should you put most of your effort?
- jcbrand 5y ago
  Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could. In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in. This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite. As they say "measure twice, cut once".
ahmaman 5y ago
> It would be cool if code-reviews were done "anonymously" Sometimes during code-reviews I find myself wanting to leave 100+ comments. Instead I settle for the few major ones and leave behind most of the minor stuff. I don't want to be perceived as someone who is difficult to work with, so try to pick my battles wisely. Wonder if anonymous code-review that helps with that.
- layer8 5y ago
  Writing style and thoroughness etc. of the comments could still be a give-away.
- absurddoctor 5y ago
  I’ve no experience with anonymous reviews, but have had experience with two approaches that help with the minor comments. One is an agreed upon method of identifying potentially minor comments. We call them ‘nits’, with the understanding that they can be dismissed by the code submitter without any changes. The second is the opposite of anonymous reviews where we meet up and have a ‘live’ review. This makes going over any such bits pretty quick and painless, as it avoids the back and forth that text comments sometimes result in. It has the added benefit of being able to discuss the ‘why’ of things more easily, which is especially useful if the reviewer is less familiar with the code involved.
- onpensionsterm 5y ago
  I do the nitpicking reviews but, when I review someone for the first time, I specifically point out that I leave nitpicking reviews and don't block approval on most of them.
- vsareto 5y ago
  I don't know, if coding is art, then the reviews need to be more personal. Anonymous art criticism usually isn't useful. You'll have to filter too much noise to get a signal. If you have an art mentor who knows you and your work, their feedback is much more useful. An anonymous code review might only be to make sure everything technically works (as securely as possible).
- hinkley 5y ago
koonsolo 5y ago
Coding is partly art, just like architecture. I'm 42 and have been coding since 14, so I feel I can also chime in :). I don't think anyone can really "code correctly". Sometimes, the code just falls into place, and you end up with something simple and clean. Other times, you're struggling, and your gut feelings tells you it doesn't feel right. But your feature needs to be finished, so you mark it as "good enough". Sometimes when you need to apply changes to some old code, it fits in nicely. That means your original code was pretty spot on. Oh what a wonderful feeling. Other times, your old code was messy to start with, and this new thing means you have to rewrite a big part of it. Like I said, coding is party art, where you need to balance a lot of opposing forces.
GuB-42 5y ago
It is funny to mention Fabrice Bellard on a topic about clean code when one of his many achievements is to have 3 winning entries in the IOCCC.
- rawoke083600 5y ago
  Haha true true ! Maybe he is a cross-spectrum coder ?
  - bitwize 5y ago
    From What I understand Bellard's code is fairly "dirty". FFmpeg, as I understand it, was hard to modify, maintain, or integrate with. Don't get me wrong, he's a fucking wizard. He's Mozart when the most talented of us can only ever hope to be Salieri. But part of that is, he dashes off brilliant code without much thought to its maintainability, then leaves for the next project.
    - rawoke083600 5y ago
      Yea sorry, I guess I could have picked my "heros" with more care maybe add in a John Carmack ? :) >Don't get me wrong, he's a fucking wizard. He's Mozart when the most talented of us can only ever hope to be Salieri. But part of that is, he dashes off brilliant code without much thought to its maintainability, then leaves for the next project. Absolutely agree's - Well that is "maybe" one unpopular-metric we need to consider as well ? - How much brilliant code can you ship that has a big impact ? I could spent 1 year to "correctly-code some system" but if no one cares or uses it.. does the code or the "better quality" even matter ?? #BigPictureKindOfWay ? To be clear, I have no idea what is the correct answer here :)
      - bitwize 5y ago
        That's the thing about Bellard. I don't think he cares really whether his code has an impact or not. And yet it does.
CapsAdmin 5y ago
> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" Outside of work in the free and open source community, I find myself often wishing that I could just get a random person who has no context of the codebase to review a piece of code I've written. Context is obviously important, but the lack of context can also highlight issues that you would be blind to if you have the context. I would want this to exist within an ide where you could highlight code, submit for review and wait. And if you want to review you can explore pieces of code to review filtered by language within the ide.
- richardfey 5y ago
  Not only anonymously, they should be published all at once (yes, the risk of duplicate feedback is totally worth it); someone please submit a GitHub feature request ;)
gashmol 5y ago
I think there is another big issue related to Clean Code (and friends) that is rarely discussed. There are two types of design methods: those that help you to generate a solution to the problem and those that only help you to optimize a solution, in some dimension, once you have one. Clean Code guidelines clearly belong to the latter. When you first write code you should not think of Clean Code. It will distract you from solving the problem at hand, while not providing any help in solving it. Only after you have a correct working solution you should consider Clean Code and other optimization guidelines. (Code Complete is much better IMO.) Knowing when often pays better than knowing how.
matwood 5y ago
No code survives first contact with the user. Code is messy because of the impedance mismatch between the (mostly) precise world of computers and the real world. So, we do the best we can knowing that 'correct' is always just over the next hill.
- hinkley 5y ago
  I think I’ve learned more about what makes good code by watching people trying to use code than from anything else. I have been doing this since college, when people would hear me helping my roommate finish an assignment so we could go home, and ask more questions. Some people are just out of their element. Some tools are just garbage even though they were written by clever people. Some tools are just garbage because they were written by clever people. At least a third of the time if a promising junior doesn’t “get it” it’s because there’s nothing to “get”. The code I/we wrote doesn’t explain itself well, misses a useful behavior that would make it more obvious how to use it, or drastically simplify a feature. These people, particularly these situations, teach me more than I teach them.
gilbetron 5y ago
I've got about a decade more of coding over you and I can confirm the same. The only time you see "clean code" is trivial examples. Get a project that needs to do something complex, and suddenly it becomes not so clean. That's because the real world is messy and complex and solutions are almost always the same. I love your priority list, although I'm scratching my head over the order - not that it is wrong, but I don't know if it is exactly what I would do. There are cases where I will take more state to be (a lot) less complex, for instance. Big surprise that even that priority list is a bit messy ;) I think the most damning thing about Clean Code is that the author has barely written any software for decades. I mean, I like the guy well enough, and he has some ok stuff to say, but he is far from someone people should listen to like a messiah. Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there.
- rawoke083600 5y ago
  >The only time you see "clean code" is trivial examples. Get a project that needs to do something complex, and suddenly it becomes not so clean. That's because the real world is messy and complex and solutions are almost always the same. Absolutely ! :) >Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there. Oh ja ! I definitely should have added Carmack to that list !!
- vasili111 5y ago
  >Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there. Could you please give the links?
  - gilbetron 5y ago
    Sure, Jonathan Blow is a game developer and he has a couple of great playlists on youtube: https://www.youtube.com/user/jblow888/playlists https://www.youtube.com/user/jblow888/playlists I recommend the Game Engine one and the Compiler one. Note, these are not high level fluff talks like Uncle Bob gives, but in-depth, really deep thoughts and watching him make complex decisions while he is actually coding. Carmack has a bunch of talks, here's a starter: https://www.youtube.com/watch?v=dSCBCk4xVa0 https://www.youtube.com/watch?v=dSCBCk4xVa0 Again, he has produced immense amount of software, from Doom to Quake to rocket control tech to Oculus Rift VR devices.
geodel 5y ago
Great points. I guess I was following some of these rules unknowingly. In one of the project I organized code as one business functionality per package which may be unforgivable sin in "enterprise java best practices". With little duplication it makes so much simpler to see that all business rules, logic handling in just one package. The absolute common thing like database connection management etc is in some common place.

stavros 5y ago

Does e.g. Fabrice Bellard code "correctly"? Getting shit done isn't the same as "coding correctly" (sometimes it's very close to the opposite).

rawoke083600 5y ago
True - who can say ? Hard to argue with a WHOLE career that got "shit done" and WIDELY used by the world ? Maybe THAT is the metric to focus on. The value of the code versus the quality ? I honestly don't know the answer ? But I know how much of my "time and energy (as you get older you released the limiting step is your cognitive-energy not so much your actual wallclock-time) " I spent on "trying" todo code correctly which many times it means, the code doesn't get done and I end up frustrated by not shipping anything. Working for a boss, the above used to upset me a bit. Now working for myself this REALLY upsets me and my 'income' :) In these cases, I would DEF liked to have "Fabrice" getting shit-done-coding ability ? Again just my humble opinion :) Maybe coding is like a marriage... a) "You can be right or you can be happy :)" Squinting hard enough: b) "You can do things correctly or you can ship code in time that makes a difference ?" I guess the "better" you are the closer the extremes are from "b". i.e IF you are the theoretical-best-coder-that-ever-lived there is should be no "distance/friction" between "coding correctly AND shipping on time code that has an impact" ??
hinkley 5y ago
When I was young I wrote code so I could understand it. Everyone goes faster when the code looks like how they expect it to look. Some of these 10x people are really good, others have mental models that are alien, and so nobody else can touch their stuff because none of it makes a lick of sense to anybody else. These are 3x devs that make everyone else .3x devs. Writing code for me made me indispensable, then it made me a bottleneck with a stream of uncomfortable distractions in the form of people queuing up for me to answer questions or fix bugs or implement features. It was exhausting, but I was happy enough. That is, until there was a cooler project I wasn’t allowed to transfer to because I was indispensable. Figure out how to write code so other people can read it. Figure out how to write code so other people can modify it. It looks a bit like clean code, but sometimes isn’t. Occasionally it can be quite different.

asimpletune 5y ago

I love your story. Also: > >I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. That's beautiful advice. Something similar that I heard was "flow of data > dependencies > interfaces", in terms of what to worry about. Interesting how they're so similar but from different sources. But yeah, I second your experiences. Focusing on this stuff, like in code reviews for example, ends up making all other downstream concerns so much easier.

rawoke083600 5y ago
>That's beautiful advice. Something similar that I heard was "flow of data > dependencies > interfaces", in terms of what to worry about. Interesting how they're so similar but from different sources. Maybe that is clue they/we are on the right track ? Coming to the similar conclusion from different angles ? :)

bojan 5y ago

> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents. This is a generally good idea, but in small teams it can't really work. Code is in that sense a bit like handwriting, everyone has their own style, and after a long enough time in a small team you learn to recognize whose the author of the code just by reading it.

skohan 5y ago
My biggest problem with code reviews is that they are so often without value. Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. In my experience, a lot of the time code reviews are either just a task - where people try to find superficial "mistakes" just to tick a box, or worse a chance for certain colleagues to power trip and try to get other team members to submit for it's own sake.
- zoomablemind 5y ago
  > ... Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. IMO a practical benefit of a routine code review is just a shared understanding. As simple as that. Does the code look to be doing what it says it should do? Do the tests express the intended behavior? Of course, the style, the quality of code could be of attention too, but that's extras, in my opinion, as long as the functionality is understood and confirmed. I like relating this to an effort of understanding someone who speaks with an accent, be it a local dialect or foreign-originated. It does require some tolerance, but the shared understanding is the goal.
- muttled 5y ago
  > where people try to find superficial "mistakes" just to tick a box I've found this to be true in change control as well as any meeting involving people who feel they are compelled to "contribute" even if they don't have anything of value. You don't want to seem like the person who's just attending the meeting and slacking off, so if you're expected to contribute and you can't find any useful critiques, you just pick nits.

skohan 5y ago

The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/design pattern which will solve the problem in the most elegant or clever way Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem in the most pragmatic way. Maybe that's hard-coding a lot of things. Maybe that's having a small amount of repetition here and there. Maybe it's writing one long function with 1000 lines. After that it's all about continuous improvement. You spend your time solving the problem, and when your code becomes hard to work on, you spend time improving your code to make it easier to work on by cleaning things up, and adding sensible abstractions which solve the problems you actually have. In my experience, over time this approach leaves you with a very ergonomic and easy to understand codebase.

bncy 5y ago
I always felt bad for doing things "the pragmatic way", but your comment made me realize that maybe I'm just not experienced enough to embrace the fact that no code is pretty from the start. Thanks!
- skohan 5y ago
  Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written, vs what your code does? Given that, where should you put most of your effort?
jcbrand 5y ago
Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I figured this fundamental design flaw the night before we had to hand the assignment in and there was no way I could rewrite everything from scratch. I had to push through and put lipstick on this pig as best I could. In the end, I had spent way more time working on this project than my friends who had spent time upfront designing their programs instead of just jumping in. This has taught me the lesson to always first try and think things through and come up with some kind of initial design, instead of just jumping in and writing code blindly. Yes you can always refactor, but some early design mistakes can cost you a lot of time, and perhaps make refactoring unfeasible compared to a complete rewrite. As they say "measure twice, cut once".

ahmaman 5y ago

> It would be cool if code-reviews were done "anonymously" Sometimes during code-reviews I find myself wanting to leave 100+ comments. Instead I settle for the few major ones and leave behind most of the minor stuff. I don't want to be perceived as someone who is difficult to work with, so try to pick my battles wisely. Wonder if anonymous code-review that helps with that.

layer8 5y ago
Writing style and thoroughness etc. of the comments could still be a give-away.
absurddoctor 5y ago
I’ve no experience with anonymous reviews, but have had experience with two approaches that help with the minor comments. One is an agreed upon method of identifying potentially minor comments. We call them ‘nits’, with the understanding that they can be dismissed by the code submitter without any changes. The second is the opposite of anonymous reviews where we meet up and have a ‘live’ review. This makes going over any such bits pretty quick and painless, as it avoids the back and forth that text comments sometimes result in. It has the added benefit of being able to discuss the ‘why’ of things more easily, which is especially useful if the reviewer is less familiar with the code involved.
onpensionsterm 5y ago
I do the nitpicking reviews but, when I review someone for the first time, I specifically point out that I leave nitpicking reviews and don't block approval on most of them.
vsareto 5y ago
I don't know, if coding is art, then the reviews need to be more personal. Anonymous art criticism usually isn't useful. You'll have to filter too much noise to get a signal. If you have an art mentor who knows you and your work, their feedback is much more useful. An anonymous code review might only be to make sure everything technically works (as securely as possible).
hinkley 5y ago

koonsolo 5y ago

Coding is partly art, just like architecture. I'm 42 and have been coding since 14, so I feel I can also chime in :). I don't think anyone can really "code correctly". Sometimes, the code just falls into place, and you end up with something simple and clean. Other times, you're struggling, and your gut feelings tells you it doesn't feel right. But your feature needs to be finished, so you mark it as "good enough". Sometimes when you need to apply changes to some old code, it fits in nicely. That means your original code was pretty spot on. Oh what a wonderful feeling. Other times, your old code was messy to start with, and this new thing means you have to rewrite a big part of it. Like I said, coding is party art, where you need to balance a lot of opposing forces.

GuB-42 5y ago

It is funny to mention Fabrice Bellard on a topic about clean code when one of his many achievements is to have 3 winning entries in the IOCCC.

rawoke083600 5y ago
Haha true true ! Maybe he is a cross-spectrum coder ?
- bitwize 5y ago
  From What I understand Bellard's code is fairly "dirty". FFmpeg, as I understand it, was hard to modify, maintain, or integrate with. Don't get me wrong, he's a fucking wizard. He's Mozart when the most talented of us can only ever hope to be Salieri. But part of that is, he dashes off brilliant code without much thought to its maintainability, then leaves for the next project.
  - rawoke083600 5y ago
    Yea sorry, I guess I could have picked my "heros" with more care maybe add in a John Carmack ? :) >Don't get me wrong, he's a fucking wizard. He's Mozart when the most talented of us can only ever hope to be Salieri. But part of that is, he dashes off brilliant code without much thought to its maintainability, then leaves for the next project. Absolutely agree's - Well that is "maybe" one unpopular-metric we need to consider as well ? - How much brilliant code can you ship that has a big impact ? I could spent 1 year to "correctly-code some system" but if no one cares or uses it.. does the code or the "better quality" even matter ?? #BigPictureKindOfWay ? To be clear, I have no idea what is the correct answer here :)
    - bitwize 5y ago
      That's the thing about Bellard. I don't think he cares really whether his code has an impact or not. And yet it does.

CapsAdmin 5y ago

> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" Outside of work in the free and open source community, I find myself often wishing that I could just get a random person who has no context of the codebase to review a piece of code I've written. Context is obviously important, but the lack of context can also highlight issues that you would be blind to if you have the context. I would want this to exist within an ide where you could highlight code, submit for review and wait. And if you want to review you can explore pieces of code to review filtered by language within the ide.

richardfey 5y ago
Not only anonymously, they should be published all at once (yes, the risk of duplicate feedback is totally worth it); someone please submit a GitHub feature request ;)

gashmol 5y ago

I think there is another big issue related to Clean Code (and friends) that is rarely discussed. There are two types of design methods: those that help you to generate a solution to the problem and those that only help you to optimize a solution, in some dimension, once you have one. Clean Code guidelines clearly belong to the latter. When you first write code you should not think of Clean Code. It will distract you from solving the problem at hand, while not providing any help in solving it. Only after you have a correct working solution you should consider Clean Code and other optimization guidelines. (Code Complete is much better IMO.) Knowing when often pays better than knowing how.

matwood 5y ago

No code survives first contact with the user. Code is messy because of the impedance mismatch between the (mostly) precise world of computers and the real world. So, we do the best we can knowing that 'correct' is always just over the next hill.

hinkley 5y ago
I think I’ve learned more about what makes good code by watching people trying to use code than from anything else. I have been doing this since college, when people would hear me helping my roommate finish an assignment so we could go home, and ask more questions. Some people are just out of their element. Some tools are just garbage even though they were written by clever people. Some tools are just garbage because they were written by clever people. At least a third of the time if a promising junior doesn’t “get it” it’s because there’s nothing to “get”. The code I/we wrote doesn’t explain itself well, misses a useful behavior that would make it more obvious how to use it, or drastically simplify a feature. These people, particularly these situations, teach me more than I teach them.

gilbetron 5y ago

I've got about a decade more of coding over you and I can confirm the same. The only time you see "clean code" is trivial examples. Get a project that needs to do something complex, and suddenly it becomes not so clean. That's because the real world is messy and complex and solutions are almost always the same. I love your priority list, although I'm scratching my head over the order - not that it is wrong, but I don't know if it is exactly what I would do. There are cases where I will take more state to be (a lot) less complex, for instance. Big surprise that even that priority list is a bit messy ;) I think the most damning thing about Clean Code is that the author has barely written any software for decades. I mean, I like the guy well enough, and he has some ok stuff to say, but he is far from someone people should listen to like a messiah. Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there.

rawoke083600 5y ago
>The only time you see "clean code" is trivial examples. Get a project that needs to do something complex, and suddenly it becomes not so clean. That's because the real world is messy and complex and solutions are almost always the same. Absolutely ! :) >Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there. Oh ja ! I definitely should have added Carmack to that list !!
vasili111 5y ago
>Go listen to Carmack or watch Jonathan Blow's code stuff. Far more interesting things there. Could you please give the links?
- gilbetron 5y ago
  Sure, Jonathan Blow is a game developer and he has a couple of great playlists on youtube: https://www.youtube.com/user/jblow888/playlists https://www.youtube.com/user/jblow888/playlists I recommend the Game Engine one and the Compiler one. Note, these are not high level fluff talks like Uncle Bob gives, but in-depth, really deep thoughts and watching him make complex decisions while he is actually coding. Carmack has a bunch of talks, here's a starter: https://www.youtube.com/watch?v=dSCBCk4xVa0 https://www.youtube.com/watch?v=dSCBCk4xVa0 Again, he has produced immense amount of software, from Doom to Quake to rocket control tech to Oculus Rift VR devices.

geodel 5y ago

Great points. I guess I was following some of these rules unknowingly. In one of the project I organized code as one business functionality per package which may be unforgivable sin in "enterprise java best practices". With little duplication it makes so much simpler to see that all business rules, logic handling in just one package. The absolute common thing like database connection management etc is in some common place.