[dead]
Good code is like a love letter to the next developer who will maintain it
251–260 of 274 posts
Re: Good code is like a love letter to the next developer who will maintain it
#252Earlier quoted context omitted.
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
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.
> 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..
Re: Good code is like a love letter to the next developer who will maintain it
#253Earlier quoted context omitted.
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…
It does matter because what constitutes good code for some people is often terrible code for others, to the point of people making jokes about it [1]. With food, at least there is a wider agreement of what consists of good and bad. [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But we are talking about self-judgment here. What does it matter which flavour of good you expect your code to be if you actually don't believe good code by your definition can be realistically achieved?
Re: Good code is like a love letter to the next developer who will maintain it
#254Earlier quoted context omitted.
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.
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?
I have seen plenty of it, but it doesn't bother me at all, especially with IDE syntax highlighting. The near-zero-documentation policy seen in some codebases bothers me 10x more.
Re: Good code is like a love letter to the next developer who will maintain it
#255Earlier quoted context omitted.
Okay but when you see that why not just take 30 seconds and update the comment? Edit: if even 30 seconds
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…
If something like that is generating a lot of bureaucracy and time-wasting, then there are several other pressing problems that are much worse than that.
My company is heavily regulated (finance) and highly bureaucratic, but I still just merge those PRs without waiting for the CI or without even bothering clicking approve, I just look at it. When I find one myself I just merge to master or edit in Github directly. No auditor has ever batted an eye to that.
Re: Good code is like a love letter to the next developer who will maintain it
#256Earlier quoted context omitted.
It does matter because what constitutes good code for some people is often terrible code for others, to the point of people making jokes about it [1]. With food, at least there is a wider agreement of what consists of good and bad. [1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
But we are talking about self-judgment here. What does it matter which flavour of good you expect your code to be if you actually don't believe good code by your definition can be realistically achieved?
I agree with the sentiment, never said anywhere that it couldn't be achieved in a personal level. Just that defining "good code" is difficult. If you narrow down "good code" to mean "good to myself" then of course it is sad that someone doesn't believe in it.
On the other hand, I find that someone saying that "universally good code" is not possible as understandable.
I personally believe it is only really achievable in certain domains, for some others (especially for code handling a lot of essential complexity) it is borderline impossible to not have at least some uneven corners. And there's only so much you can sweep under the carpet of indirection.
Re: Good code is like a love letter to the next developer who will maintain it
#257Earlier quoted context omitted.
The customer is the one using your product, not the one maintaining your code.
A common reply, but misguided. A corporate coder who is not also CMO and CEO does not produce products for the end user. They produce code units which, after build, deploy, and integration, become useful building blocks in an overall solution which may (the company hopes) be a product for the end user. From this standpoint, the code they write will often be 'consumed' by other coders and by future themselves. The con…
Sure, but usually you develop an interface to your service/code, and they shouldn't have to know the internals.
If they have to look at your code to figure out how to use it, you've already lost. Hence the code isn't the product, it's the means.
Re: Good code is like a love letter to the next developer who will maintain it
#258Earlier quoted context omitted.
The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.
It's true that the product should take priority over the code, but there's a limit to by how much. If the code is bad enough, its low performance, bugginess, and slow feature development will eventually be reflected in the product.
Performance and bugs are product features, not code features.
Who cares if it slows down feature development if you never have to change it. If it does impact the product, it then becomes part of the product value you're delivering. This is the time you should be investing in better code.
Re: Good code is like a love letter to the next developer who will maintain it
#259Earlier quoted context omitted.
The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.
> The craft is not the code, but the product. These two are not disjoint, but instead quite related. > Your job is to deliver good product, not good code. If your job is software engineering, then "good code" is what facilitates "good product." It boils down to maximizing the "abilities": - Understandability - Applicability - Testability - Maintainability - Flexibility - Durability
Yup, good code helps to deliver a good product, but you should not focus on the code, rather focus on how the code influences the product.
Better to have hacky code that delivers value than to deliver nothing.
Re: Good code is like a love letter to the next developer who will maintain it
#260Earlier quoted context omitted.
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.
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.
> 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.