Many people might think that developers are asocial nerds. Their only interest is technology. They’re on this planet to produce the dreams of their managers.
Big surprise: this is not true.
A developer should primarily care about producing value, not code. Value for himself, value for the others, value for the clients or companies he works with.
What does producing value means, for a developer?
- Being aware about the business domain of the company he works with, to translate it correctly in software.
- Using his skills to be able to solve a wide range of problems. This doesn’t have to be related to technologies or even programming.
- Always trying to improve the quality of the codebase he works on. It has to work, being maintainable, understandable and scalable.
- Finding and designing solutions in a good amount of time.
That’s the mission of this blog: improving your value, for you to produce valuable solutions. In short, to become a good, well rounded, valuable developer, with more control and autonomy.
In order to do so, The Valuable Dev will try to respect the following principle, which, I think, will give you the values I’m speaking about.
Mindsets Precede the Tools
I usually like to define the important words in my articles, to be sure we understand each other. As Thomas Reid was saying:
There is no greater impediment to the advancement of knowledge than the ambiguity of words.
Let’s agree on what mindset means. According to the Oxford Dictionary:
The established set of attitudes held by someone.
What about a tool?
A thing used to help perform a job.
Tools are attractive: they offer concrete solutions to solve your problems and answer your needs. We are often tempted to jump on the tools without asking ourselves more questions, or because “everybody uses them”.
This is fine if we really understand what we want from them. Before using a tool, we need to explore first:
- Why do we have this need? What problem would it solve?
- What’s the goal?
- Does the need answer the goal?
- What other actions can we take to tend to this goal?
It doesn’t mean that The Valuable Dev has no article about tools. It means that I will always try to explain the possible mindsets which are linked to a tool, by answering the questions above.
Here are some examples which can help you to grasp what I mean:
- We need to know how to code before being able to use effectively an IDE. We even need to know why we need to code, at the first place.
- We need to know whats the purpose of managing our time before using time management tools.
- We need to learn some tips and tricks how to effectively manage a side project before trying to find the best tools to build it.
- We need to know why and how the agile way of developing software was created and understand its philosophy, before using blindly 192339 tools and frameworks like Scrumm, Kanban, Scrummban, Kanscrummbanummnam.
Tools provide a path, a context, and almost an excuse for developing enlightenment, but no tool ever contained it or can dispense it.
Quality Over Quantity
Many blogs out there focus on creating articles in order to attract as much people as possible. The goal? To have the best Google ranking, to see the numbers of visitors going up as quickly as possible.
I noticed something quite alarming in this trend: for some blog, the content’s quality doesn’t follow. They end up with short and artificial articles, without trying to dig a bit deeper their subjects. Obviously, the clickbait title will be there, too, and a lot of ads will pop up in your face.
The reader is accomplice in this state of affairs: more than ever, in this Twitter-world, we switch from one piece of content to another very quickly, scanning everything, even what looks interesting, instead of reading, understanding and learning.
That’s why I’m trying my best to write each article of this blog carefully, in order to give you the clearest information, the most practical tips and the best examples I can find, for you, the reader, to learn how to increase your value as a developer.
All of that implies that you need to:
- Read a bit more than 20 lines.
- Trying to understand the questions I want to answer.
- Understanding the important words and their meaning.
- Understanding my arguments.
- Understanding the general idea I want to convey.
It means asking yourself questions, agreeing or disagreeing with my point of view, and take actions if you need to. I would be happy to share any comment or feedback with you in the comment section of each article.
I understand that the length and density of some articles might look a bit daunting. They are not meant to be read at once, in 5 minutes, while speaking with your colleagues and answering your friends on Whatsapp.
What you can do is:
- Eye scanning the subtitles of the article to see if it looks interesting for you. I always try to structure my articles with many subtitles.
- Read the article slowly, in multiple sessions, using Pocket, for example.
You can think about The Valuable Dev as a mix of a blog and a book. The articles are often longer than the ones in an average blog, but shorter than a book.
At the end, I want us, you and me, to learn. I learn from my researches, my explanations and your comments. You learn from my experience, my knowledge, my researches and my analysis.
Learning the first principles of any discipline is the best way for mastery. Staying on the surface of the knowledge can help you solve common problems, but it won’t help you to adapt quickly to the new and more complex ones.
Developers often need to answer new challenges, tackle new problems. They often need to go outside their comfort zone. That’s one important reason why our job is so interesting and creative!
Would you like to be able to work on any framework, with any language, in a startup which expects quick and quality results, even if you never used these tools before?
This is my objective too: expand your foundation of knowledge, giving you more of these basic building blocks to answer quickly a broad range of technical and business needs. To be able to adapt to anything which is based on these first principles.
It might feel more difficult to take this path instead of focusing on one programming language, one framework, one tool, and staying in this comfortable bubble. However, it’s less rewarding and less interesting too.
What are these first principles, concretely? For example:
- Knowing the useful basics in computer science
- Developing your soft skills in order to learn from any situation
- Understanding how a relational database works “under the hood”
- Understanding development good practices without applying them blindly in any situation
You might think: “I don’t need to know how the universe works to bake an apple pie!". You would be right. I don’t think learning how the universe work would help you. Knowing the first principles of cooking, however, could enhance the quality of your apple pie and the time you need to bake it.
Let’s try to focus on the first principles which really matter, for you to become an expert in the software world.
Future Proof and Coherent
Most of the articles on this Blog are meant to be atemporal. I try to describe some general concepts which will stay relevant in the future.
That’s the benefit of the first principles: they change pretty slowly or even not at all. Object Oriented Programming, for example, is around for decades and didn’t evolve that much since its wide adoption in the development world (at least, one of its flavor).
It means that you can read the “old” articles of this blog and still find relevant information.
Even though, the articles’ publication date as well as their last update dates are displayed, for your information. I’m trying to update the articles as often as possible, in the light of new experiences, new knowledge and the changes in the industry.
The Valuable Dev is meant to be coherent: many articles are linked together with hyperlinks. It’s not mandatory to read everything of course, each articles can be enjoyed independently.
Experimenting Is Key
I don’t have every answer, or even The Truth©, whatever it is. I deeply think that what is true depends on the context.
- Almost every general rules have exceptions, depending on what you try to achieve. Every decision you make needs to be done trying to perceive the possible outcomes. That’s why, in some case, what I hold for true in general might be false in some case.
- Some tips and methods will work well for some people, for others they won’t. I encourage you to experiment for yourself, and see if my advice apply to you. Trust your guts, and don’t hesitate to challenge your new knowledge with concrete experiments overtime.
The last statement is even more true when your own self is a part of the equation. For example: time management methods, tips to decrease your stress, how to fight procrastination, and so on.
Let’s not forget another scenario: I might be plainly, indisputably wrong.
I think when a piece of content, shadowed by the writer, meet the reader, an interaction begin. The reader might disagree, for purposely reasons, about what he’s reading. However, the writer has no chance to answer readers’ concerns: the communication goes only one way.
That’s why the comment section is so valuable. It allows us to interact and learn from each other. Between the readers and the writer, or between the readers themselves. Never, in the history of mankind, we had the chance to learn from everybody so easily!
Let’s capitalize on this fantastic opportunity to bring value to our knowledge and, ultimately, to our lives. Quality comments, that is, with well-thought arguments, can offer another aspect of the subject and enrich the knowledge proposed, for everybody.