3 ms·

I used to get mad at other engineers for this. A lot of them didn't seem to take much pride in their work. Then I realized that people take pride in different

I used to get mad at other engineers for this. A lot of them didn't seem to take much pride in their work. Then I realized that people take pride in different dimensions of their work. Perhaps for one person it's well-factored code, for another person it might be design and user experience and overall polish, for another person it might be the ultimate effect of the product being built on the customers (or on the business). And even on each of these there is infinite room to give a shit or not about different components of them. All too often, being obsessive about code cleanliness is a type of bikeshedding among geeks who have gone so far down the rabbit hole that they can't engage meaningfully with the world through anything but code. Or have been so disempowered through years of cruddy jobs and sitting at the kids' table that they haven't reason to try. It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles. Code quality is only important in service to other goals.

RougeFemme 14y ago
Put another way. . it's hard sometimes to recognize - and accept - the influence of all the other stakeholders in the project, around and above you. And sometimes it's hard to deal with the 80/20 rule and stop polishing the apple. . .the apple might not be shiny enough for you, but other people don't even the apple that you are continually shining.
dmiladinov 14y ago
> It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles. This. Sometimes it's really hard to tell when you're shaving a yak instead of fixing broken windows. What are some ways to tell you're doing the wrong one?
- pekk 14y ago
  Yak-shaving isn't necessarily a waste of time. Sometimes you have to spend time on something locally suboptimal to get something closer to globally optimal. With the "weekend project" idea it seems that we easily forget how real jobs often require time and struggle, even for smart people.
freshhawk 14y ago
> All too often, being obsessive about code cleanliness is a type of bikeshedding "All too often"? Is it? I hear this all the time and very very rarely actually see it. It definitely exists, but our community seems to treat this unicorn as if it's the major issue affecting productivity. Way way more often I see the opposite. "Just ship it! Lean startup!" a month ago leads to the inability to ship now because every part of the code you touch to add a new feature results in everything breaking. And of course there's no unit tests or any kind of documentation or even agreement among those working on it regarding what responsibilities each part of your system has. It inevitably results in the dreaded "big rewrite", if you haven't fallen behind your competitors enough at this point and are still in business. Like you say, it's a balance and a hard one but I'm getting more and more convinced that this false consensus results in bad advice, especially when non-technical people start throwing around "just ship" and "move fast and break things" without even knowing there is a balance. There is also absolutely no context to this lean advice that this balance is completely different for different types of programming. You will never get a good search engine written by "moving fast and breaking things", you're going to have to do some architecture/design work before you start writing code. But if you are setting up a wordpress blog to do affiliate marketing then by all means just fucking ship it. Maybe I'm living in a bubble that's very different from everywhere else? Where people went too far with good advice? If that's the case then I want out! I will hire some obsessive bike shedders and teach them to consider time as an important factor. Way easier than trying to retrain people who think that loose coupling or not putting every method you can think of into one monster class is "obsessive perfectionism".
samwize 14y ago
The key is to pick the correct battle.

RougeFemme 14y ago

Put another way. . it's hard sometimes to recognize - and accept - the influence of all the other stakeholders in the project, around and above you. And sometimes it's hard to deal with the 80/20 rule and stop polishing the apple. . .the apple might not be shiny enough for you, but other people don't even the apple that you are continually shining.

dmiladinov 14y ago

> It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles. This. Sometimes it's really hard to tell when you're shaving a yak instead of fixing broken windows. What are some ways to tell you're doing the wrong one?

pekk 14y ago
Yak-shaving isn't necessarily a waste of time. Sometimes you have to spend time on something locally suboptimal to get something closer to globally optimal. With the "weekend project" idea it seems that we easily forget how real jobs often require time and struggle, even for smart people.

freshhawk 14y ago

> All too often, being obsessive about code cleanliness is a type of bikeshedding "All too often"? Is it? I hear this all the time and very very rarely actually see it. It definitely exists, but our community seems to treat this unicorn as if it's the major issue affecting productivity. Way way more often I see the opposite. "Just ship it! Lean startup!" a month ago leads to the inability to ship now because every part of the code you touch to add a new feature results in everything breaking. And of course there's no unit tests or any kind of documentation or even agreement among those working on it regarding what responsibilities each part of your system has. It inevitably results in the dreaded "big rewrite", if you haven't fallen behind your competitors enough at this point and are still in business. Like you say, it's a balance and a hard one but I'm getting more and more convinced that this false consensus results in bad advice, especially when non-technical people start throwing around "just ship" and "move fast and break things" without even knowing there is a balance. There is also absolutely no context to this lean advice that this balance is completely different for different types of programming. You will never get a good search engine written by "moving fast and breaking things", you're going to have to do some architecture/design work before you start writing code. But if you are setting up a wordpress blog to do affiliate marketing then by all means just fucking ship it. Maybe I'm living in a bubble that's very different from everywhere else? Where people went too far with good advice? If that's the case then I want out! I will hire some obsessive bike shedders and teach them to consider time as an important factor. Way easier than trying to retrain people who think that loose coupling or not putting every method you can think of into one monster class is "obsessive perfectionism".

samwize 14y ago

The key is to pick the correct battle.