6 ms·

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the e

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except be far more cautious about where and who I spend time around. Even this very thread has some pretty bad vibes: “who can say what good code is?” “good code can’t exist with deadlines.” I feel really bad for junior/intermediate devs that read this stuff and internalize it.

Gigachad 3y ago
Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. And then that person leaves the company and no one else truly understands how it works or was meant to be used so it gets a series of hacks and patches applied to it which violate the original design which is known by no one at the company. For most projects this is not that big of a deal, the component gradually becomes less coherent and the original requirements change so much that one day someone will decide that the whole thing will be rewritten from scratch.
- thumbuddy 3y ago
  And this is why Go lang exists... The trade off is screw brilliant engineering just make it simple so other people can build on it easily. Not saying it's my favorite, but it has it's merits long term.
  - AdieuToLogic 3y ago
    A semantically weak language does not reduce the inherent complexity of a system, as problem complexity is constant. What Go does is encode solution complexity implicitly throughout a code base. This is the same effect JavaScript often has.
    - whstl 3y ago
      Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business. But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.
      - kaba0 3y ago
        Then why not assembly is the ideal program language? Ad absurdum, that’s the simplest, isn’t it? Each line does something completely trivial. Abstraction is the only tool we have to even hope to manage complexity. Unfortunately there is no way to force good abstractions, finding out the perfect abstraction is the deal of the art. Maybe I’m wrong on this, but I’m on the elitist view that the industry really shouldn’t try to replace a single senior developer with 10 juniors that monkey patch based on stackoverflow/chatgpt. I don’t even see how that makes financial sense, if one values product quality.
        whstl 3y ago
        Because, obviously, too little abstraction is as bad as too much abstraction. The way to combat excess is not with more excess. There are no automated to enforce good abstractions, but languages and tools can serve as a way to shepherd programmers into avoiding or preferring certain patterns. This is an argument as old as the programming language field itself. For some people Golang strikes a good balance. I'm not one of those people, but I have learned to respect it.
        thumbuddy 3y ago
        Assembly is a lot harder to write correctly/safely than go lang is. Comparing the two seems disingenuous. I do agree with you to some extent about not replacing senior engineers. But a "bad" senior engineer who is "too smart" for their own good can do more damage then juniors following a template. All things in balance for sure.
- spondyl 3y ago
  For anyone interested in a discussion about the concept of systems not being understood by newcomers, I can recommend Peter Naur's Programming as Theory Building: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
  - mikmoila 3y ago
    Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.
  - kaba0 3y ago
    Just commented the exact same thing without checking if someone else also posted, because it is not that well known for some reason.
- whstl 3y ago
  That's often the rationalization for most "perfect" and "ultimately reusable" code I see, however what I've seen too many times is code that ended up turning into shit even when the creator remained the sole maintainer. Blame often gets passed upwards to some product manager or sales coming up with some outlandish business requirement, but honestly the real reason is that the code wasn't that flexible to begin with. Which is perfectly fine, not all code can be flexible and infinitely reusable. Perhaps we should stop forcing every single file to be.
- quietbritishjim 3y ago
  > Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable). Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.
  - The_Colonel 3y ago
    I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.
    - K0balt 3y ago
      The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
      - The_Colonel 3y ago
        > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.
- deleted 3y ago
  [deleted]
- dingi 3y ago
  This is true if you assume that the abstractions identified by the original author is correct and adequate for the life of that app. Usually, it's not the case. There are slight deviations that makes previous abstractions unusable for new requirements and the new dev has to start from the beginning
gavinhoward 3y ago
> I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. I've had several people comment on the quality of my code. For a FOSS project. Of a command-line tool that nobody cares about. People notice. But yeah, this article is too much fluff because people don't see it that way. Half of the people who commented on my code mentioned the snarky comments I wrote.
- psunavy03 3y ago
  A study apparently found that open-source code with profanity in the comments was statistically measured to be of higher quality. https://blog.desdelinux.net/en/el-open-source-con-malas-palabras-en-los-comentarios-es-estadisticamente-mejor-que-el-codigo-sin-ellas/#:~:text=We%20hypothesize%20that%20the%20use,%22%20the%20study%20report%20says.%20 https://blog.desdelinux.net/en/el-open-source-con-malas-pala....
  - jraph 3y ago
    Discussed on HN 17 days ago [1] As said there, this might as well be simply a correlation with commented code. Or, people swearing might be an indication of having taste. [1] https://news.ycombinator.com/item?id=36584464 https://news.ycombinator.com/item?id=36584464
  - gavinhoward 3y ago
    I don't swear, so this is my replacement.
molsongolden 3y ago
I’ve hunted down contact info and emailed a dev who’d left the company to thank them for the clean code they left behind. I encountered their code while debugging weird behavior in a legacy feature. The code structure was immediately intuitive and comprehensible. Just the right amount of detailed but not superfluous commenting. Beautiful. It made my day so I let them know!
- wouldbecouldbe 3y ago
  I never had code where I was like, oh this has too many comments. I never get this sentiment from developers. I've had reviews were developers wanted me to slim down & rewrite comments. It's often hard in the moment to understand what's obvious or not. Just always writing a comment even if it's obvious can save a lot of pain in the future.
  - danbruc 3y ago
    You have never seen a comment that helpfully explains that getUsername() returns a string with the username of the user that the method is invoked on?
    - CodeyWhizzBang 3y ago
      Or the classic result of updating the code but not updating the comment: //Returns the user's full name return user.email;
      - andelink 3y ago
        Okay but when you see that why not just take 30 seconds and update the comment? Edit: if even 30 seconds
        dack 3y ago
        in a collaborative environment, it's rarely 30 seconds to make such a change though. usually you have to make a commit with message, make a PR, submit the PR and get someone to review it (many orgs require code review for every change), then merge it. And each of those steps usually require you to context switch from whatever else you were actually trying to get done. Now, if you're already changing that part of the code/file, then sure it's pretty low overhead. But for something as simple as that function, I'd probably delete the comment entirely.
deleted 3y ago
[deleted]
lelandbatey 3y ago
Let's share our gratitude indeed; it's like a warming fire. I have had extraordinary coworkers who wrote incredibly solid code that was a joy to work with at every turn. When some of those coworkers have moved on, I've bought them thank you presents and taken them out for a meal to say thank you for making a difference. It's a token gesture in the face of how much I've learned from them and their wonderful work. My message is to all of us who work away in the trenches of our day-to-day, where we stare through straws and move grains of sand; please let us shout and celebrate the granules of gold that our peers produce!
yMEyUyNE1 3y ago
It takes a master to recognize a master's work. Know that you have made their work easy even if they don't realize it.
atoav 3y ago
I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong. Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures. Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team.
- matjazmuhic 3y ago
  Seems like a duplicate to which my reply is here: https://news.ycombinator.com/item?id=36811381#36811433 https://news.ycombinator.com/item?id=36811381#36811433
- gkhartman 3y ago
  "Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong." Anyone who's worked on a construction site would agree that this is not too far from reality. I agree, it's quite sad, but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt.
  - atoav 3y ago
    > but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt. That would be my question. We are not talking about people saying that within their context good code is not possible, we are talking about people who say good code is not possible, period. Maybe burnout has to do with it, maybe also depression. But I even if I was stuck in a job that made me churn put half broken code all day I'd still remember my hobby projects in which I experienced myself that perfectly fine code can be written by a single determined person — and quite frankly: it doesn't even have ro take that much longer, it just has to be a trusted, concentrated low pressure environment.
atoav 3y ago
I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong. Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures. Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team. This isn't always a simple thing, but it must be done. The saddest aspect is that you see many experienced software developers who never experienced things working well. And as someone who sometimes writes code for fun I cannot understand that at all. What I get is that throughout your professional life you can never had the chance to be in a project where you could write good code. However you can write good or even perfect code at home where nobody pressures you. And if it is possible there, why wouldn't it be in a professional context?
- whstl 3y ago
  But what is "good code", even? For some people that's thousands of two-line methods in hundreds of classes where each part is easy to understand. For others it is more direct code that is optimized for debugging, but not as aesthetically pleasant. Very often those two groups people dislike each other's code a lot. And there's even more other "groups" than those obvious two.
  - atoav 3y ago
    Does that question really matter for this discussion? Every developer will have their own flavour of what constitutes good or bad code, but independent of their flavour isn't a software engineer who doesn't believe in the possibility of achieving good code a somewhat sad thing? Imagine being a cook that doesn't believe in the possibility of cooking good food — sure what constitutes good food is a matter of discussion, but if you have a cook that doesn't believe in it that alone is remarkable in itself.
    - 3y ago
agumonkey 3y ago
other colleagues not caring is one thing, your company not recognizing the value and giving you the adequate compensation is another.. I don't mind if colleagues don't appreciate as long as I don't have to either lower my skills or be underpaid
- mattgreenrocks 3y ago
  I interned somewhere where I wrote a 56k modem codec decoder. That particular codec relies on decompression by streaming bits out, which is something awful. Was able to deliver it by summer’s end. After I graduated college in 2004, they hired me at 50k. I didn’t know my value.
  - agumonkey 3y ago
    > I didn’t know my value. which is one the important point yet a very difficult information to get what is mind blowing is how ignorant but somehow subconsciously proud (dunnig-kruger kind of way) will bully themselves into higher salaries (I've seen them repeatedly) while the good working, caring craftman will not and stagnate at lower pay. worst of all is when the low skill guy becomes your boss..
madeofpalk 3y ago
Most people might not appreciate "good code" but they'll sure as hell un-appreciate bad, unreadable code.
unconed 3y ago
One of the saddest moments was hearing a smart person with barely a few years of experience insist that code always degrades in quality and there's nothing you can really do about it... Never saw them try.
codingdave 3y ago
Agreed. At the same time, my customers are downright joyous when the code works and solves their problems. I've had numerous occasions where people were thrilled to meet me and gave me more hugs and praise than I was comfortable with once they heard that I created certain tools they use. So while I do try to write good code, if you are looking for appreciation, it comes from what the code does, not how it is written.
jjav 3y ago
> I don’t think I’d do much differently in retrospect, except be far more cautious about where and who I spend time around. Another angle here is that code has become seen as something with the shelf life of a banana. People today talk of code merely a year old as legacy that needs to be rewritten ASAP. If one grew up in a world where code is scheduled to be thrown away as soon as it gets to production, I guess I can see how quality of code and documentation doesn't matter at all. That's not a happy world though. I grew up with the codebases of Unix (particularly SunOS, later Solaris). Code lives on for decades. One matures it to perfection and then it's perfect for a long, long time. That's a much more pleasant way to honor the craft.

Gigachad 3y ago

Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. And then that person leaves the company and no one else truly understands how it works or was meant to be used so it gets a series of hacks and patches applied to it which violate the original design which is known by no one at the company. For most projects this is not that big of a deal, the component gradually becomes less coherent and the original requirements change so much that one day someone will decide that the whole thing will be rewritten from scratch.

thumbuddy 3y ago
And this is why Go lang exists... The trade off is screw brilliant engineering just make it simple so other people can build on it easily. Not saying it's my favorite, but it has it's merits long term.
- AdieuToLogic 3y ago
  A semantically weak language does not reduce the inherent complexity of a system, as problem complexity is constant. What Go does is encode solution complexity implicitly throughout a code base. This is the same effect JavaScript often has.
  - whstl 3y ago
    Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business. But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.
    - kaba0 3y ago
      Then why not assembly is the ideal program language? Ad absurdum, that’s the simplest, isn’t it? Each line does something completely trivial. Abstraction is the only tool we have to even hope to manage complexity. Unfortunately there is no way to force good abstractions, finding out the perfect abstraction is the deal of the art. Maybe I’m wrong on this, but I’m on the elitist view that the industry really shouldn’t try to replace a single senior developer with 10 juniors that monkey patch based on stackoverflow/chatgpt. I don’t even see how that makes financial sense, if one values product quality.
      - whstl 3y ago
        Because, obviously, too little abstraction is as bad as too much abstraction. The way to combat excess is not with more excess. There are no automated to enforce good abstractions, but languages and tools can serve as a way to shepherd programmers into avoiding or preferring certain patterns. This is an argument as old as the programming language field itself. For some people Golang strikes a good balance. I'm not one of those people, but I have learned to respect it.
      - thumbuddy 3y ago
        Assembly is a lot harder to write correctly/safely than go lang is. Comparing the two seems disingenuous. I do agree with you to some extent about not replacing senior engineers. But a "bad" senior engineer who is "too smart" for their own good can do more damage then juniors following a template. All things in balance for sure.
spondyl 3y ago
For anyone interested in a discussion about the concept of systems not being understood by newcomers, I can recommend Peter Naur's Programming as Theory Building: https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- mikmoila 3y ago
  Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.
- kaba0 3y ago
  Just commented the exact same thing without checking if someone else also posted, because it is not that well known for some reason.
whstl 3y ago
That's often the rationalization for most "perfect" and "ultimately reusable" code I see, however what I've seen too many times is code that ended up turning into shit even when the creator remained the sole maintainer. Blame often gets passed upwards to some product manager or sales coming up with some outlandish business requirement, but honestly the real reason is that the code wasn't that flexible to begin with. Which is perfectly fine, not all code can be flexible and infinitely reusable. Perhaps we should stop forcing every single file to be.
quietbritishjim 3y ago
> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable). Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.
- The_Colonel 3y ago
  I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. Very much this.
  - K0balt 3y ago
    The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.
    - The_Colonel 3y ago
      > If you know that code will be extended to accept additional fields Well, you rarely know, more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.
deleted 3y ago
[deleted]
dingi 3y ago
This is true if you assume that the abstractions identified by the original author is correct and adequate for the life of that app. Usually, it's not the case. There are slight deviations that makes previous abstractions unusable for new requirements and the new dev has to start from the beginning

gavinhoward 3y ago

> I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. I've had several people comment on the quality of my code. For a FOSS project. Of a command-line tool that nobody cares about. People notice. But yeah, this article is too much fluff because people don't see it that way. Half of the people who commented on my code mentioned the snarky comments I wrote.

psunavy03 3y ago
A study apparently found that open-source code with profanity in the comments was statistically measured to be of higher quality. https://blog.desdelinux.net/en/el-open-source-con-malas-palabras-en-los-comentarios-es-estadisticamente-mejor-que-el-codigo-sin-ellas/#:~:text=We%20hypothesize%20that%20the%20use,%22%20the%20study%20report%20says.%20 https://blog.desdelinux.net/en/el-open-source-con-malas-pala....
- jraph 3y ago
  Discussed on HN 17 days ago [1] As said there, this might as well be simply a correlation with commented code. Or, people swearing might be an indication of having taste. [1] https://news.ycombinator.com/item?id=36584464 https://news.ycombinator.com/item?id=36584464
- gavinhoward 3y ago
  I don't swear, so this is my replacement.

molsongolden 3y ago

I’ve hunted down contact info and emailed a dev who’d left the company to thank them for the clean code they left behind. I encountered their code while debugging weird behavior in a legacy feature. The code structure was immediately intuitive and comprehensible. Just the right amount of detailed but not superfluous commenting. Beautiful. It made my day so I let them know!

wouldbecouldbe 3y ago
I never had code where I was like, oh this has too many comments. I never get this sentiment from developers. I've had reviews were developers wanted me to slim down & rewrite comments. It's often hard in the moment to understand what's obvious or not. Just always writing a comment even if it's obvious can save a lot of pain in the future.
- danbruc 3y ago
  You have never seen a comment that helpfully explains that getUsername() returns a string with the username of the user that the method is invoked on?
  - CodeyWhizzBang 3y ago
    Or the classic result of updating the code but not updating the comment: //Returns the user's full name return user.email;
    - andelink 3y ago
      Okay but when you see that why not just take 30 seconds and update the comment? Edit: if even 30 seconds
      - dack 3y ago
        in a collaborative environment, it's rarely 30 seconds to make such a change though. usually you have to make a commit with message, make a PR, submit the PR and get someone to review it (many orgs require code review for every change), then merge it. And each of those steps usually require you to context switch from whatever else you were actually trying to get done. Now, if you're already changing that part of the code/file, then sure it's pretty low overhead. But for something as simple as that function, I'd probably delete the comment entirely.

deleted 3y ago

[deleted]

lelandbatey 3y ago

Let's share our gratitude indeed; it's like a warming fire. I have had extraordinary coworkers who wrote incredibly solid code that was a joy to work with at every turn. When some of those coworkers have moved on, I've bought them thank you presents and taken them out for a meal to say thank you for making a difference. It's a token gesture in the face of how much I've learned from them and their wonderful work. My message is to all of us who work away in the trenches of our day-to-day, where we stare through straws and move grains of sand; please let us shout and celebrate the granules of gold that our peers produce!

yMEyUyNE1 3y ago

It takes a master to recognize a master's work. Know that you have made their work easy even if they don't realize it.

atoav 3y ago

matjazmuhic 3y ago
Seems like a duplicate to which my reply is here: https://news.ycombinator.com/item?id=36811381#36811433 https://news.ycombinator.com/item?id=36811381#36811433
gkhartman 3y ago
"Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong." Anyone who's worked on a construction site would agree that this is not too far from reality. I agree, it's quite sad, but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt.
- atoav 3y ago
  > but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt. That would be my question. We are not talking about people saying that within their context good code is not possible, we are talking about people who say good code is not possible, period. Maybe burnout has to do with it, maybe also depression. But I even if I was stuck in a job that made me churn put half broken code all day I'd still remember my hobby projects in which I experienced myself that perfectly fine code can be written by a single determined person — and quite frankly: it doesn't even have ro take that much longer, it just has to be a trusted, concentrated low pressure environment.

atoav 3y ago

I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong. Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures. Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team. This isn't always a simple thing, but it must be done. The saddest aspect is that you see many experienced software developers who never experienced things working well. And as someone who sometimes writes code for fun I cannot understand that at all. What I get is that throughout your professional life you can never had the chance to be in a project where you could write good code. However you can write good or even perfect code at home where nobody pressures you. And if it is possible there, why wouldn't it be in a professional context?

whstl 3y ago
But what is "good code", even? For some people that's thousands of two-line methods in hundreds of classes where each part is easy to understand. For others it is more direct code that is optimized for debugging, but not as aesthetically pleasant. Very often those two groups people dislike each other's code a lot. And there's even more other "groups" than those obvious two.
- atoav 3y ago
  Does that question really matter for this discussion? Every developer will have their own flavour of what constitutes good or bad code, but independent of their flavour isn't a software engineer who doesn't believe in the possibility of achieving good code a somewhat sad thing? Imagine being a cook that doesn't believe in the possibility of cooking good food — sure what constitutes good food is a matter of discussion, but if you have a cook that doesn't believe in it that alone is remarkable in itself.
  - 3y ago

agumonkey 3y ago

other colleagues not caring is one thing, your company not recognizing the value and giving you the adequate compensation is another.. I don't mind if colleagues don't appreciate as long as I don't have to either lower my skills or be underpaid

mattgreenrocks 3y ago
I interned somewhere where I wrote a 56k modem codec decoder. That particular codec relies on decompression by streaming bits out, which is something awful. Was able to deliver it by summer’s end. After I graduated college in 2004, they hired me at 50k. I didn’t know my value.
- agumonkey 3y ago
  > I didn’t know my value. which is one the important point yet a very difficult information to get what is mind blowing is how ignorant but somehow subconsciously proud (dunnig-kruger kind of way) will bully themselves into higher salaries (I've seen them repeatedly) while the good working, caring craftman will not and stagnate at lower pay. worst of all is when the low skill guy becomes your boss..

madeofpalk 3y ago

Most people might not appreciate "good code" but they'll sure as hell un-appreciate bad, unreadable code.

unconed 3y ago

One of the saddest moments was hearing a smart person with barely a few years of experience insist that code always degrades in quality and there's nothing you can really do about it... Never saw them try.

codingdave 3y ago

Agreed. At the same time, my customers are downright joyous when the code works and solves their problems. I've had numerous occasions where people were thrilled to meet me and gave me more hugs and praise than I was comfortable with once they heard that I created certain tools they use. So while I do try to write good code, if you are looking for appreciation, it comes from what the code does, not how it is written.

jjav 3y ago

> I don’t think I’d do much differently in retrospect, except be far more cautious about where and who I spend time around. Another angle here is that code has become seen as something with the shelf life of a banana. People today talk of code merely a year old as legacy that needs to be rewritten ASAP. If one grew up in a world where code is scheduled to be thrown away as soon as it gets to production, I guess I can see how quality of code and documentation doesn't matter at all. That's not a happy world though. I grew up with the codebases of Unix (particularly SunOS, later Solaris). Code lives on for decades. One matures it to perfection and then it's perfect for a long, long time. That's a much more pleasant way to honor the craft.