Koodihommia

A family friend of mine is an airlane pilot. A dream job for most, right? As a child, I certainly thought so. Now that I can have grown-up talks with him, I have discovered a more accurate description of his profession. He says that the truth about the job is that it is boring. To me, that is not that surprising. Airplanes are cool and all, but when you are in the middle of the Atlantic sitting next to the colleague you have been talking to past five years, how stimulating can that be? When he says the job is boring, it is not a bad kind of boring. It is a very specific boring. The "boring" you would want as a passenger. Uneventful.  Yet, he loves his job. According to him, an experienced pilot is most pleased when each and every tiny thing in the flight plan - goes according to plan. Passengers in the cabin of an expert pilot sit in the comfort of not even noticing who is flying. As someone employed in a field where being boring is not exactly in high demand, this sounds pro...

Developers should read Ralph Waldo Emerson. By read, I mean listen to a 30-minute podcast and claim expertise. Emerson says being too opinionated is harmful. The cliche in tech is that the view from the window of kosher technologies shifts quickly. The result is that I've been mostly wrong about any given technical issue in my career. I'm not saying this to be unpretentious but rather a fact.  Given I'm wrong and write poor code at a given moment is not to be interpreted that something is left permanently broken. The great thing about having loose opinions is that I'm always open to implementing a better solution. It may still ultimately be sub-par but better than the original. Ralph Waldo Emerson says that we should not imitate others. That may not end up as a quote in a programming book, though. No one likes a genius, and a clever thinker can be an insult in a coding context. Seeing something you have seen thousands of times in your editor is usually desirable. Widen ...

Of all the horrific code I have written, by far, the most harmful and destructive have involved too early abstraction. Everyone knows the issues stemming from the wrong abstraction. Even copy-paste code would have been a better choice than creating some seemingly fancy, say, adapter pattern implementation. To be honest, I think copy-paste has a worse reputation than it should. A given project might have started with best practices, module structure, libraries of a prior project/16k star primer. That can be good! Some best practices naturally transcend projects. We should bring in the lessons learned but the timing matters. Upon a closer look, the project might indeed have agreeable abstractions. Still, those could be hollow and bring only extra LOCs and solve the issues faced in the previous projects, which have never occurred in the current one. Upon recently starting two soon-to-be large projects, I learned to leave some wisdom from previous lives behind. While deep in the coding zen...

I recently pulled an apparently small item from the backlog. It was to add a guided tour, a showcase of the essential features of the app. Naturally, I search for an open-source library that would do the job, and Bob's your uncle. There are a few alternatives to pick from. Yet, they seem just not quite fit the need here. All of them require excessive changes to the existing implementation instead of just plug and play. In cases like these, how do I draw the line, when to use a library, when to DIY. First of all, I have a high do it yourself threshold.  I generally think that almost any reasonably used OS library is a better option than DIY. You probably are a worse developer in the domain of the library than the community behind it. You also have not yet run into all those corner cases and weird bugs that come biting you back. Even if the dependency may bring something you don't need, I see it as a worthwhile trade-off. I'll skip the frameworks vs. libraries debate here. If...