Many people might think that developers are asocial nerds. Their only interest is technology. They are only there 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 the company he works with, proposing the best solutions for immediate results, using his skills to be able to solve a wide range of problems.
That’s the mission of this blog: improving your value, for you to produce value. In short, to become a more well rounded, valuable developer.
In order to do so, The Valuable Dev will try to respect the following principle, which, I think, will bring a lot of value for you, the reader.
Mindsets Precede the Tools
I usually like to define the important words in my articles, for us to agree on their meanings. 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 way 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 it”.
This is fine if we really understand what we want from them. However, would a tool be useful if you have the wrong set of attitudes?
We need to explore first:
- Why do we have this need? What problem would it solve?
- What is the goal?
- Does the need answer the goal?
- How can we tend to the goal?
Here are some examples which can help you grasp what I mean:
- We need to know how to code before being able to use effectively an IDE, and we even need to know why we need to code, at the first place.
- We need to know what the purpose of managing our time before using time management tools.
- We need to know 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 what it is about, before being able to use 192339 tools and framework like Scrumm, Kanban, Scrummban, Kanumm, Kanscrummbanummnam.
It doesn’t mean that The Valuable Dev has no article about the tooling. It means that I will always try to explain the possible mindsets which goes with a tool. It’s your choice to adapt it to your needs or to simply reject it.
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 many 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 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 advertisements 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 my arguments, the important words and their meaning, 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 understand that the length and density of some articles might look a bit daunting, but many of them are not meant to be read at once, in 5 minutes, while speaking with your colleagues and answering your friends on Whatsapp.
You can think about The Valuable Dev as a mix of a blog and 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 and the analysis I make by combining the two.
Learning the first principles of any discipline is the best way for mastery. Staying on the surface of things, on the artificial side of the knowledge, can help you solve common problems, but won’t help you to adapt quickly to the new, deeper and complex ones.
Developers often need to answer new challenges, tackle new problems. They sometimes need to go outside their comfort zone. That’s one important reason why our job is so interesting!
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 longer and 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.
What are these first principles, concretely? For example: knowing the useful basics in computer science, understand how a relational database works, understand memory, even if you work only with high level languages.
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 principle which really matters, 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 are meant to 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.
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.