Nobody tries to make a mess in software development, it just happens over time. Like cords behind your computer. You never said, “Today I will tie these in in knots”, It’s a side-effect of our actions. You moved a cord to one side then later moved it to the other side and in doing so caused a tangle to form. Over the months, it gets worse and worse till it becomes a rats nest.
The same thing happens with software development.
You never mean to pass down 20 props 7 levels in your React components.
You never mean to create an 800 line file.
You never mean to have 7 different names for the same concept.
You never mean to forget to delete code that isn’t ever run.
It happens when you do nothing but add features.
Why? Because we’re focused on a small aspect of the system when we’re building a feature. Our one goal is usually to “get it done” and we often don’t see the effect on the larger system. It’s good not to be sloppy but impossible to never make a mess while doing normal work.
So, What do we do? One way is to try to design things better. Design its core is about intentional thinking. It’s about planning things out before you act. Look, then step.Hindsight is 20/20
But the true antidote to the problem of iteration is to be more backward thinking. Hindsight is 20/20 and you can use this to your advantage.
Every so often in a project, take time to clean things up, not connected to feature work.
Some people feel that this is a failure of diligence, “If we’re always creating quality code, we wouldn’t need to clean it up!” This is like saying, “only bad cooks have dirty kitchens!” This might be true if they never clean it, but it’s unrealistic to keep it clean if you are always cooking.
Maybe cooking isn’t the best software analogy but writing a book is actually a lot closer. So how do good authors write?
There is no such thing as good writing, only good rewriting. ~ Robert Graves
Writing a novel is always hard, but it’s impossible if you try to never make any mistakes. Fixing every red line will make you feel better about the sentence but it will be a waste of time when you realize the whole chapter isn’t worth keeping. You’ll get bogged and quit before you wrote anything at all because it’s all going too slowly.
This is why editing and writing should be separate.
Also, avoid the extremes of the editing/writing spectrum. Either you’ll end up with a well-manicured paragraph or a sloppy 500-page novel. You need both editing AND writing. And they should happen at frequent intervals.Creating mind V.S. Cleaning Mind
When you’re creating you have a very specific mindset. You’re all about the goal. This means thinking about all the constraints and finding your way to the solution.
Cleaning is a much more meta way of thinking. It’s not about using the tools to make things, It’s about organizing the tools so you can make things faster. Let’s get rid of all the stuff that doesn’t “spark joy” so we can close the drawers.
You see, the real core of the problem is that we’re bad at multi-tasking. So focusing on one thing at a time is crucial for us being effective. When I’m cleaning a weird thing happens where I see all the dirt, all the problems become more and more plain. It’s like everything suddenly got dirty when I started looking for it but in reality my focus had changed.The Bi-Modal approach
Bi-Modal means you have two modes of working, in this case, building and refactoring. When you build, build. But make sure to take some dedicated time too refactor at a regular interval. Look at your code at a high level and see if it makes sense. Break up big files, Merge concepts and standardize naming, and Document anything that could be confusing and couldn’t be better. Explain your reasoning.
You have to be pragmatic and not it takes months but it’s going to take longer than a day. I like Basecamp’s 6 weeks build, 2 weeks clean cadence. It’s a nice ratio of how often you need to clean compared to build. But even they will do a “bug smash” around the holidays where they spend a 6 weeks fixing stuff.
If you haven’t cleaned in a while it’s going to take longer but the more you stay on top of it, the less of a chore it will be. Not only that but you’ll start to love your codebase. And you might just write documentation.
You can use Mastodon through an alternative web client if you prefer. One of the most popular is Pinafore, which is lightweight and FOSS.
The example website is at https://pinafore.social
The source code is at https://github.com/nolanlawson/pinafore
Because it's free and open source, you can host the web client yourself if you want to.
Its creator has written an introductory post with more info about it:
I'm working on listening 🙂👂 and empathy 🤗
so I wrote some of my mistakes.
and some of my more successful attempts
and what made the difference.
Hey.com adds personal blogging and newsletter features for no additional cost.
Good news from #Mozilla: “Any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to that website, such that it is not allowed to be shared with any other website.”
What's your thoughts on Object Oriented Programming? I've kind of fell into a "func-peritive" style since programming since writing Elixir.
Most functions aren't pure, and are called what they do. I do however use immutable data, which I like.
I always feel like I've never really "got" OOP. It always seems indirect to have to create an object to simulate something. It seems easier to understand to just "do the thing". I feel like this is how users think as well. "I just want X done"
I've often wondered how I can better understand how to spread innovative tech and ideas (such as #asynchronous communication) and this is really eye opening about it. I'll probably transcribe my notes here for those interested 😁.
INDIEWEB.SOCIAL is an instance focused on the #Openeb, #Indieweb, #Fediverse, #Mastodon #Selfsovereign #identity (#SSI), #Humanetech and #Calm technologies evolution.