Creating a map of knowledge and tools for engineers, by engineer
I am Vitalii Lakusta and my mission with Map for Engineers is to create a knowledge base, a map, to capture and index engineering ideas that are worth exploring. I write about software engineering, building valuable products as an engineer, engineering leadership, building engineering teams and being effective in a team. Recently I published an article on the Engineers of Pactum blog (I work in Pactum), called Values, Principles and Practices in Engineering Team. This is an example of the content you can expect on Map for Engineers.
I am not doing Map for Engineers full-time nor do I plan to. I am working full-time as engineering lead (manager+actively coding) at Pactum at the moment. I love my job. I believe that by staying sharp and being in the engineering field actively, I am more likely to produce higher-quality content, and this is my priority - quality over quantity in Map for Engineers. Before Pactum, I worked as an engineer in such companies as Wise (fintech), Starship (autonomous robots), and I was CTO at Better Medicine (medical tech). My LinkedIn.
Also, in addition to writings, I would like Map of Engineers to be a podcast soon as well, where I could discuss relevant and fundamental software engineering-related topics with my guests. More news on podcast later, once it’s actually realised, but this is a little heads up about what to expect.
My values and principles for Map for Engineers
My values are:
Quality over quantity. I would like to maximize the value you get per time you spend on Map for Engineers.
I don’t tell what people should do. I simply share my perspectives and opinions. Sometimes I get sick from posts like “5 things you should do to become amazing engineer”. Who am I really to tell you what you should do? All of us make choices based on our very unique circumstances. In my writings, I will try to avoid to tell you “you should/must do this or that”, but rather I am striving to share my experiences, reflections, and perspective. I would like you to draw your own conclusions. I am just as you. We are learning together. You should think for yourself, and make your own choices. Instead of saying “You should…” I might say “Consider this option, because of reasons A, B, and C”. No silver bullets.
Be real. Honest. Don’t be pretentious. Instead of using words like “if you do this, you will grow 100x”, I better say, “if you do this, that might improve for you”. I will try to stay real and use simple accessible words and language. I will try to not use grandiose language.
Perfect is the enemy of good. A reminder for myself not to fall into analysis paralysis. If the content I want to share is valuable - make it good enough, but then ship, post it. Don’t be paralyzed because the blog post you wrote isn’t perfect. I can iterate after it’s shipped.
Learn from others. A reason why I also want to do podcasts with guests - not to be in the bubble, but to have invigorating and real conversations with other fellow engineers about interesting topics, where there are no straightforward answers. Also, this value means for me that I am willing to receive feedback from you.
A few guiding principles as well:
Expand knowledge base, which can be navigated effectively. I think who comes to my mind is Martin Fowler - he follows this principle very well. On martinfowler.com, Martin made a Bliki section with a terminology and concepts that serve as a really good knowledge base for engineers (for example Martin’s recent bliki about Cycle Time). Over time, I would like to categorize articles and podcasts into concrete themes, so it would serve as the knowledge base.
Prioritize fundamentals over hype or trends. Invest and prioritize into writing about topics that don’t change often, write about fundamentals much more than about fleeting hyped topics. For example, writing about a team psychology, team dynamics, fundamentals of software design. At the same time, I am willing to cover relevant topics and experiment with trends or emerging promising tech. For example, writing about augmenting engineering work with LLMs is a very relevant topic, even though the writing might be deprecated soon since the LLM tech moves so fast.
Sharing and indexing great external resources over re-inventing the wheel. If someone wrote some great article, which I love, about a certain engineering topic, I will happily share it here. I will only share things that I personally believe provide a great value. Over time, I hope that Map for Engineers, in addition to original content here, will be a good hub with easy-to-navigate links to great external articles, courses, lectures, properly categorized and indexed. It’s a good idea to stand on the shoulders of giants! Whenever I share some external resource, I will provide the context on why I am sharing it.
If you feel like it’s something for you, feel free to subscribe.
