The ability to make things happen using a coding language and some lines of code is great and super important, but unfortunately it is not enough to define one as an independent developer. Because, in my opinion, development is not all about coding.
I will define a developer to be independent if, as a manager, I can say they make my life easier. What does it mean? Well, basically it means that I don’t have to keep tracking their progress continuously. I know they can manage themselves and make the right decisions about their own progress within a project or a task.
Let me define the qualities of such an engineer with a story from my experience as a developer -
Lately, I got a wonderful opportunity to have a “free time” for independent development of my choice, within the company I used to work for at the time. I wanted to take advantage of that time and freedom, to innovate, and create something new that will be valuable and make an impact.
Sounds great huh? But in order to actually succeed in such a mission, one has to approach it with care, and think carefully on what to do, and how to do it.
How are we going to decide what to do? Well -
Understanding the business is a must!
As developers, we tend to focus only on the ‘How’. However, I believe it is our duty as developers, to understand the Why as well. On all my development roles in the company, I always took the time to deep dive into the big picture, and understand the vision and the missions of the company as a whole. I examined the business needs, the products required, and the technological challenges. I took the time to think carefully about the products we are developing and the things that should be done differently to gain efficiency and better results.
After a few years, I got to a point where I could ask myself the important questions, such as “what is missing? What can be done better?”. Thus, when I had the chance for free time development, I knew exactly what I wanted to do, and I had some good sense about its impact.
Being an independent developer does not necessarily mean you have to innovate all the time and create things on your own. Understanding the business, understanding the business-value of the tasks that you do, will make you confident about the development, and will make the final result more precise to the business needs.
Even on bigger projects, when we are part of a team, and we get our specific tasks from the manager/PM, we still have to understand the big picture. It is super-easy to ignore it as a developer, and concentrate on the challenge of programming it, testing and deploying it.
Developing the ability to understand the reasoning of the product, and our specific tasks within it, is one of the most important qualities of an independent developer.
Once we have an idea for a project or a product, whether it is ours or not, it must be validated. A validated idea is an idea that its impact worths the time and resources needed in order to develop it.
Eventually, working a lot on something, deploying it, and then discovering it has little impact after all the hard work, is frustrating, wasting some valuable time, and costing the company a lot of money.
The process of validating a product’s value is very important, and should be done quickly and efficiently. We, as developers, have the ability to support this process with our greatest ability — coding!
Challenging the value of an idea using coding
Once we know the ‘Why’ of a project or a task, we can validate its impact using development tools in really short time. In my experience, most of these validations can take less than a day, if deeply thought through. For example, it can be done by identifying the critical component, and focusing on its assessment and validation (usually technical challenges), or creating a mock to demonstrate an expected output (usually fits to usability challenges). Just to be clear, I’m not referring to an MVP (this will be the next step), but rather an experiment to prove the applicability of an idea and to assess resources needed in order to develop it.
My project was about taking large amounts of real-time data that was not used by analysts at the time at all, aggregate the metadata of the real-time events (in a month resolution), and export it through a CLI (command line interface). Through the aggregated metadata, I believed the analysts could gain a lot of new information, relevant to their tasks.
I started by defining a mockup to experiment the impact of my idea. The mockup was as follows: the final CLI that will be used by the end users, and a set of simulated aggregated data (in the final output format) without any backend.
Once I built it, it was super easy to check how valuable it is going to be. I met as many senior analysts in my organization as I could and showed them my mockup. From my experience, it is much easier to discuss and receive feedback when you have something to show, and this is why fast developed mockup is useful.
I received the feedback, made the needed adjustments to the CLI mockup. All and all, it took me less than 2 days to have an impactful product definition.
Eliminating unknown technological variables
After validating the impact of an idea, it is time to make technological decisions. Independent developers, that are familiar with the business and the value of what they are trying to create, are able to make technological decisions that are far more intelligent.
Just like we experimented in the previous step of challenging the value of the idea, experiment-driven-development might be really useful here as well. we need to validate the technology, to make sure developing the idea will worth the time and resources.
In my experience, the fastest way to make technological decisions, is by validating first the most complicated things. In order to do that, we needs to map all the crucial parts of the development first. In my case, I had a few of them -
- Extracting the metadata in real-time from the streamed events
- Aggregating the metadata in a month resolution
- Storing the aggregated data
Now, by deciding which part is going to be the most complicated (for me, it was A, then B, then C), we can start experimenting. Choose one, ignore all the rest, and try to prove it is possible to develop it in the time frame you have. The fastest you realize whether certain parts are too complicated, the better technological decisions you can make.
We, as developers, tend sometimes to put away the complicated things, and to deal with them later on the way. This behavior is harmful, and makes you an irresponsible developer. Be independent, know the complications, and deal with them as soon as possible.
Code Responsibly — Think Through
So close to coding now! after realizing the technological challenges and dealing with them, it is time to plan our development. We have all the information needed. It is time to think about our MVP. An MVP, Minimum Viable Product, is the most basic product that will give the most impact in the shortest time possible.
Since I had all the information I needed from previous stages, it was quite easy for me to decide by myself on the best MVP. I decided to create my MVP with one feature (out of 4 planned), minimum durability (which basically means all my real-time data was inserted to Redis and queried from there), but maximum performance (Redis is the best!).
Deciding how your MVP is going to look like is important at least as understanding your idea is going to be valuable. This decision has so much in determining whether you are going to succeed in being productive and valuable in short time. It is so easy to think that many things are a must for an MVP, and that the product will not be usable without them, but you must think, and be aggressive, about what should be there, and you must take advantage of the experiments you conducted before.
In my case, everyone told me that the durability of the data I create is the most important thing. It is important (losing a month of data is expensive), but I knew it is going to be problematic over time, in terms of performance, and I also knew Redis. I knew there is a way to configure it later to be persistent (in a way), I knew it is probably the easiest to set-up, most stable, super-fast and with very friendly API, at least for what I needed at the time. I decided to give up on durability for now, and to use Redis for my main data-store technology.
Then, I could create a real MVP. Took about 4 days until I had a running, batch-processed aggregated data with simple CLI. Received feedback easily, made the adjustments for another day and moved on.
From there, everything was quite easy. The system was running, and I just had to adjust, and develop according the plan I created (tasks such as real-time, more CLI functions, durability etc..). From here, it is a simple development.
In conclusion, we discussed four qualities of the independent developer -
- The ability to understand deeply the business needs, and what is going to be the impact of every task being done.
- Being able to conduct experiments in order to support the impact validation process. Thinking deeply on how to conduct such experiments fast and efficient.
- Mapping the technological complications, and dealing with them as soon as possible, before thinking on how to implement an MVP.
- Planning carefully the development, especially the MVP, based on the experiments conducted before.
being an independent developer basically means to think. Think carefully on each and every step, challenge the ideas, the solutions, the technology. Being independent means to have the least possible unknown variables, both in terms of the product and its value and technology.
