How does a programmer not have to reinvent the wheel?

There are many bicycles in our business. The simplest, most common tasks have already been done before you – this is a fact. Each of these tasks can have a million solutions, probably every programmer at least once in his life has written his own sorting or some other simple things. So fighting against bicycles – inventing things that have already been invented many times before you – is one of the sore topics in our industry.

My own personal tip of the day

After 20-odd years of programming I came to the following conclusion: everything was written a long time ago. Working with the base, working with the legacy system, working with the UI, working with user input, and so on – it’s all been written by someone, and most likely more than once. Disclaimer: if, of course, we’re talking about a common programming language like Java, C#, Python, etc. If it’s a newly emerging language, it’s very likely that nothing has been written there yet.

I do recommend working in a common language. And not just because it’s easier and a lot has already been written. Working in a new language makes it harder for you to find a job in the market, you have an unclear future situation, and you have to choose a job from what’s available rather than what you like. But back on topic.

If you’re working in a common language, there’s no point in writing something that’s already written. And if we’re looking at C#, almost everything is written by Microsoft there, so you just take a ready-made solution and implement it. Why reinvent the wheel? You don’t need to use your own crooked solution when there is a much more elegant and correct one.

You only write your own solution that deals with the business logic, the subject area and issues specific to your company. It can’t be written by anyone else but you.

Looking for an off-the-shelf solution first

In fact, this is also quite a non-trivial task. Especially if you work in a bloody entreprenuership and have a bunch of projects. In many cases it’s almost impossible to find out if what you need is written there. I’ve solved this issue for myself by asking my roommates/floormates if they’ve written anything similar. If they haven’t, that’s the end of the search. Because looking for something that could have been written 15 years ago is useless. If we’re talking about enterprise software, in many cases even if something relatively similar to your problem was solved, it can only be relatively similar. It can happen that adapting that solution for your problem will cost more than writing it from scratch.

If you’re a junior-middle specialist, it’s not your job at all to find out if someone else wrote it. That’s a conversation for a junior+ specialist, teamleader, or architect. Whether we re-do the task or use a ready-made solution is an architectural question. There are a lot of pitfalls that lower level specialists simply will not see.

If you are a signor, you need to learn how to build networking. Your effectiveness as a professional is largely determined by your ability to network with people within the company than your hard skills. If you’ve gotten to know and befriend other teams well, it’s very likely that you’ll solve complex tasks that require weeks of coding much faster. Simply by knowing who to ask and taking a ready-made solution rather than writing everything all over again. For some reason this aspect is ignored by most programmers.

Algorithm of action

  1. First you check whether the functionality you need has not been previously written by someone else. If it is working with something common (working with the database, working with the UI, etc.) – it is definitely written, you should not write it yourself. You should use an off-the-shelf framework. Talk to the team about what framework you will use for the case and work with it.
  2. If the question is related to business logic, your domain and things specific to your company – ask your project colleagues if they have written something similar. If not – write it yourself.