11–20 of 78 posts
And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier.
Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it.
To get over the procrastination I would set up a Pomodoro timer and set it to 20 minutes, and just write something, any code. I made it a joke to write the crappiest code I could, to make it fun, as long as it works. Inline copy pasta, etc. Later on it turned into the goal of the most understandable code, over everything. I would never have done this out of the university, but this was 10 year later. Before I would come up with a "plan" or "design", but at that point, I would just hack something up.
What I found was with starting with an excellent blank CI/CD project, and a good BDD end-to-end testing strategy, I could write "dirty code first" to "just get it done" ... then once I got into a OODA loop, refactor it into amazing products and services while having fun. This reduced my cognitive load and emotional overhead. Coding is actually 5% of the work, the rest is QA, requirements gathering, meetings, UX/UI designs, and overhead.
I wonder if you can formalize this a bit more. Let W(init,DC) be the initial cost (hours/effort) of writing Dirty Code (DC). Let's assume that the code works for the intended purpose and doesn't have any bugs. Let W(init,CC) be the initial cost of writing Clean Code (CC). You'd expect it to be related to W(init,DC) by some proportion: W(init,CC) = (1+alpha)*W(init,DC). Then there is a probability p that you will want…
Then there is the severity of the potential failure. So the additional risk should also encompass both the probability of failure when extending code and the severity of that failure.
[1]http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…
Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work, and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.
This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source. Then when he shows the visualization I was…
> The idea that, basically, bad code no one ever has to touch again is in fact good code How do you know no one would ever have to touch that code again, at the moment of writing it? Nevertheless, generally I agree that isolated complexity is much better than complexity that spreads everywhere through explicit or hidden dependencies (e.g. global state). So dirty complex code hidden behind a simple API is actually not…
When you find something real blood-curdling but the last commit in that file was three and a half years ago, you just close it and pretend you didn't see. Better to spend the effort somewhere it will definitely benefit someone soon, rather than maybe some day.
> Or maybe I decide to squeeze in an extra if-statement in already tricky code. And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier. Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place bett…
>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it. Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work , and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.
This was a fun read for really personal reasons. The idea that, basically, bad code no one ever has to touch again is in fact good code, is in fact "better" in a true sense than carefully engineered code accomplishing the same thing, has been a really valuable guiding insight for me in my career. I couldn't remember where I got it though, or if it even had one single source. Then when he shows the visualization I was…
So there is a script or something with the book that you can run on your Git repo to see a chart of the hotspots?
Then visualize it however. I have some d3 scripts that came with the book that I've modified and you can track down somewhere on github I'm pretty sure. I mostly use those for demoing it to devs unfamiliar with the techniques though, since it looks cool and is immediately obvious what it's for.
For serious use I dump it into sqlite and use a mix of different scripts and techniques to figure it out. It's been kind of a language playground for me over the years so is in a lot of different languages and is "learning code" in most of them. Cleaning them up and sharing is one of those "maybe some day" things though.
I was let go once for having too many commits in a PR. When we squash merged… I’ve come to the same conclusion about code quality. If it’s something that others interact with, make it polished. If it’s something only you interact with, make it commented.
You were fired for having too many commits in a PR? That seems like an extreme overreaction unless there's more to the story.
I had a quick look through the codebases showcased on the CodeScene site, and across them, the files with most churn tend to have quite generic names (like core, daemon, helper, internalEngine, etc).
It sort of supports my intuitive take on the answer: the "churniest" areas of the code are the ones that were initially difficult to think of in specific terms, ie, the ones that don't tend to implement one thing, but boundaries between things. They're the catch-alls, the areas where our conceptual abstractions don't fold together as neatly as we'd like.