Be careful how you choose your tools
Everyone knows this situation: you are tasked – or want – to do something and need to decide on the how.
What is a how
Your “how” can be pretty much everything. An approach, a tool, a method, an algorithm, a mindset, a way. If you do a task – I’d argue any task you need to select some of these; let’s call them “tools”.
Your choice of tools matters greatly. It will affect how long you take, what the final result looks like, how usable it is, and most importantly: if you have fun you working on a project.
Let’s assume we wanted to create an API to interact with our already existing service. Our tools would be anything we need to get the API. In this case:
- the programming language
- your editor/ide
- the operating system you work on
- the desktop you use
- the API schema
- how you solve problems
- your attitude towards the work you do
Make these choices wisely. Some may be easy to change at a later time, some are not. So how would we approach this?
Let’s take this choice as an easy example of what factors in. It should be reasonably fast; but since we are just writing an API even Python would do.
Now we need a strong, reliable network stack. This does not rule out anything either since networking is practically a base-requirement in the 21st century. Now we want to be reasonably fast when developing it.
We want to have clean code. Do we want to burden ourselves with the corset of OOP? Some may argue that this is easier because “that’s what they already know”, I don’t. Depending on how strict your language is with it’s enforcement of OOP-Principles. Do you really need something like ruby’s “this integer is an object”, or would it at least benefit you? I’d argue that you don’t and it would not. (If you disagree, feel free to do so. This does not have to be true for everyone.)
Now I want to use a programming language I am comfortable with.
And suddenly we have the programming-language to use. Sure, researching all this may take a while but I’d argue that taking a bit more time upfront may save you time in the long run.
Why does this matter?
Some may know the dictum that goes something like “you can ‘hammer’ a nail with a wrench, but do you want to?” Funnily enough, I was just recently reminded that actual people are answering this question with a yes. Saying something like “it’s not stupid if it works” or “well, I have this wrench anyway”. I’d like to take a moment and respond to this:
That’s an extremely stupid and short-sighted way of working. “It works” is not equal to “it works well” or even “it’s functional”.
Doing something in a certain way, because we don’t want to use our little thinky spots is not only harmful but outright dangerous. This is how people start using excel as a database. Don’t be that guy.
Oh, by the way
Maybe some solution has advantages another does not have, which in turn has it’s own advantages. Don’t just brush those off. These are probably the most important decision steps. This is where you decide if you value speed and efficiency more than human readability.
And for fuck’s sake; don’t use Excel as a database!
Do you know better? Have a comment? Great! Let me know by sending an email to ~firstname.lastname@example.org
If you feel like it, you can donate.
Unless stated otherwise the texts of this website are released under CC-BY and code-snippets under the GPL.
© Moritz Poldrack