4 ms·

I don't recall ever having worked on a large code base with a team of developers where everyone was 100% happy with it. Developers complain about everything. It

I don't recall ever having worked on a large code base with a team of developers where everyone was 100% happy with it. Developers complain about everything. It's never good enough and never will be. I believe this is related to our brains being hard-wired to prioritize negative phenomenon and stimuli. Most of those projects shipped and were successful. Users did like using them. However the developers often only saw the bug reports and the endless requests for new features. They never got a chance to talk to users and see how the software was being used and improving the lives of real people. They only see the barb-wire and duct tape. I had a young developer ask me once about refactoring: how do you get time to refactor your code? Never. You will never find a person willing to hand you a paycheck to take a month to change absolutely nothing. It gives the business no advantage. But the bugs! the young developer says. To which I say, dear summer child, risk tolerance. The business is willing to take the chance that 1-2% of the time a user may get frustrated, encounter a bug, and file a report or complaint. If the company has to pay you to fix it later that's fine. They can tolerate the cost. You refactor your code as you go. After you write the code and your tests pass and you think you're done -- refactor first. Abstract away superfluous variables with function application, remove duplicated code, break up long branches with decision tables, etc. Fix that code up before you check it in. As you get better your refactor steps will be much shorter as you internalize the data structures and patterns that lead you to clean, concise code to begin with. When you write software commercially you need management that understands how to balance capital, people, and technology. And you need engineers who are pragmatic about their work and the real outcomes: the systems and the people who use them.

pdimitar 7y ago
> You refactor your code as you go. That's one of my most valuable self-taught truths! I fought with management and colleagues for years until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains both the desired feature (or fix) and the refactoring that slightly improves the status quo of the code. This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.
- dep_b 7y ago
  The word "refactoring" to software managers has the same ring as "prostate exam" or "speculum" to the rest of us. It might be necessary sometimes but Preferably Not Today and please stop talking about it all of the time.
  - pdimitar 7y ago
    Yeah, agreed. I stopped using it altogether when I am not talking with programmers. I usually just say "when adding this new thing you have to re-fit everything else so all parts play nice with each other", or "you know how you have to pull the engine out so you can fix the frontal suspension? that's what I have to do sometimes". Both of these are accepted pretty well by non-technical people.
celticmusic 7y ago
while I agree with you, your description of refactoring scares me. It makes me imagine an over-engineered hot mess. I had a conversation with a junior engineer just today about valuing simplicity and avoiding abstractions until you're sure you really need them. because cleanliness isn't really the goal, the goal is meeting business needs, stability, and discoverability. Often times abstractions create complexity, and that complexity hurts discoverability, it potentially hurts stability, and it can often times be detrimental if business needs change. So I say abstract when it's clear that you need to, not before. That's not to say I disagree with the sentiment to get the code working and then go back over it with an eye for cleaning it up, I just dislike the sentiment that this cleanup should be for abstracting things.
- agentultra 7y ago
  I realize I said, Abstract away superfluous variables with function application which is not the kind of over-engineered mess you're warning us about. I'm referring to lambda abstraction, that is replacing an expression with a name and closing over the free variables in it with the parameters to the function. The reason for this is that assignment is a common source of errors in imperative programs. We should aim to use as few of them as possible, define them local to their use, and limit their scope. I'm only talking about small, local refactors that make the code yo wrote easier to understand and maintain. Refactoring code to introduce new patterns or re-architect a module are better done earlier in the process and much more deliberately, I agree.
  - celticmusic 7y ago
    No one thinks their overengineered mess is an overengineered mess, that's kind of the point.

pdimitar 7y ago

> You refactor your code as you go. That's one of my most valuable self-taught truths! I fought with management and colleagues for years until one day, after a 4-day weekend, it just struck me: nobody can tell me anything when my PR contains both the desired feature (or fix) and the refactoring that slightly improves the status quo of the code. This was ~5 years ago. From then to today, I hear complaints about my PRs about 2 times a year.

dep_b 7y ago
The word "refactoring" to software managers has the same ring as "prostate exam" or "speculum" to the rest of us. It might be necessary sometimes but Preferably Not Today and please stop talking about it all of the time.
- pdimitar 7y ago
  Yeah, agreed. I stopped using it altogether when I am not talking with programmers. I usually just say "when adding this new thing you have to re-fit everything else so all parts play nice with each other", or "you know how you have to pull the engine out so you can fix the frontal suspension? that's what I have to do sometimes". Both of these are accepted pretty well by non-technical people.

celticmusic 7y ago

while I agree with you, your description of refactoring scares me. It makes me imagine an over-engineered hot mess. I had a conversation with a junior engineer just today about valuing simplicity and avoiding abstractions until you're sure you really need them. because cleanliness isn't really the goal, the goal is meeting business needs, stability, and discoverability. Often times abstractions create complexity, and that complexity hurts discoverability, it potentially hurts stability, and it can often times be detrimental if business needs change. So I say abstract when it's clear that you need to, not before. That's not to say I disagree with the sentiment to get the code working and then go back over it with an eye for cleaning it up, I just dislike the sentiment that this cleanup should be for abstracting things.

agentultra 7y ago
I realize I said, Abstract away superfluous variables with function application which is not the kind of over-engineered mess you're warning us about. I'm referring to lambda abstraction, that is replacing an expression with a name and closing over the free variables in it with the parameters to the function. The reason for this is that assignment is a common source of errors in imperative programs. We should aim to use as few of them as possible, define them local to their use, and limit their scope. I'm only talking about small, local refactors that make the code yo wrote easier to understand and maintain. Refactoring code to introduce new patterns or re-architect a module are better done earlier in the process and much more deliberately, I agree.
- celticmusic 7y ago
  No one thinks their overengineered mess is an overengineered mess, that's kind of the point.