I've recently started reading Four Thousand Weeks: Time Management for Mortals. The essence is (my apologies to the author if I'm butchering it) that you'll always have too much to do, and you'll always be too busy and that all we can reasonably do is to be attentive of this and make wise tradeoffs - and not to try and do everything.
There's a common saying in software development that you should hire lazy developers - the reason being that they'll do whatever they can to reduce the amount of work they have to do. Need to search through hundreds of text documents for email addresses? No way is a lazy developer doing it by hand, they'll come up with a program to do the hard work for them. But there's a fine line: is it still better to write a program to solve a labour intensive task if it takes much longer to write the program than just doing it by hand? Developers have a tendency to create tools to do all sorts of things, and many times they make life easier, but many times they also increase complexity and slow people down.
At what point do time saving features of programming languages begin to take up more time than they save? It's something I've been thinking about constantly throughout my career. On the one hand if your code is straightforward but verbose it can be very quick to read and understand. If you've seen a piece of code a hundred times you can be pretty damn sure that there isn't anything funky going on. The downside of course is that there's just more code and, despite my previous sentence, even simple code will contain bugs at some point.
Smart people have come up with many time saving ways to create software products: all-in-one frameworks such as Ruby on Rails that (as long as you know the framework) allow you to create web applications with lightning speed, code generation tools that take a high level description of your API and spit out the boilerplate code leaving only the implementation to you. One more recent tool that I've come across, Hasura, allows you to expose your database directly as a graphql endpoint. Providing one of the most attractive no-code experiences as almost all of the traditional CRUD "backend" code is handled by the tool.
These are all fantastic tools of course, but what happens when you hire a promising young intern who is proficient at coding, but isn't familiar with all the tricks? Suddenly your time saving solutions become the bottleneck and a more verbose, but straightforward code solution would be faster for them to work with. It could just be that the intern needs to learn all of these tricks before they become productive. My core question, I suppose, is: is it possible to have your cake and eat it? Is it possible to do all the common stuff trivially and at the same time have it in a familiar form (i.e. code in a standard language)?
My intuition is that it's possible, but I haven't seen quite what I'm thinking of here. Leave a comment and let me know what your favourite tools are below!
Top comments (0)