Becoming a developer

My name is Rodrigo Pontes and this is my personal blog with thoughts on my path to becoming a software developer.

There is no fixed schedule for posts. So please leave your email if you want to be notified of future posts:

Up to September 2016, at 37 years old, all my professional experiences were around sales and marketing. In November I started to study web development full-time. In June 2017 I was hired as a junior front-end web developer at a medium-sized startup. I want to share what I was thinking in October, the month I decided to change careers.

A decision based on passion and money

This would be the title if I were to share this post on LinkedIn redacted by a BuzzFeed editor with a penchant for soap operas. And a very misguided title it would be. Basing a professional decision in potential money is not a very good idea. Basing a professional decision in passion is a terrible idea.

Passion frames the decision the wrong way and is detrimental to the point, joy provides a better context. The lure to advise someone to follow their passion on their career decision is understandable. Passion is both clickbaity and aspirational, making it the sugar of processed career advice. It tricks your brain into making you think that you should care about whatever is consumed with it. The little truth in this advice is that how you feel about a profession should indeed count on the decision. But passion gives you a context of absolute, urgent feelings welded to present-time circumstances. For decisions that will shape years in your future, it is better to base them on more relative, perennial feelings aligned with more fundamental values.

I believe a better concept might be 'joy'. Do you enjoy the everyday activities you will be executing in this profession? But it is tricky. Joy is a feeling and feelings change a lot and we project them through all dimensions of our lives. So it helps to think relative to other potential professional choices, not comparing to leisure activities or in absolute terms. On a good day, when you are happy with your friends and family, it is a great sunny day out there and you have to work: would you prefer to be coding or working in one of your other career options? And on a bad day, feeling sad and confused with some personal issues you don't know how to solve and you have to work: would you still prefer to be coding than the other work options?

Money is part of the equation, but a too narrow focus on it is counterproductive. Money fulfills a useful role as a goal and, for some people, as motivation. But obsessing about it increases the ever-present pernicious risk of letting the outcome overshadow the process. The practical effect of it is to make us think we deserve the outcome and not that we should earn it, which nearly guarantees a life of under-achievement and frustration. Software development is full of high paying jobs, but money is the outcome of job performance and career choices. Small digression: Luck is also a factor, but it is a constant of the equation, not a variable we can control. Office politics is yet another factor, but even if some people can use it as a controllable variable to earn more money, it is more of a constant when considering the decision of changing careers. End of digression, back to thinking about career choices and job performance.

So consider what are your career choices on software development. A good start is to answer this question: "How good are the jobs in my area that would be suitable for me?" Your area can be your city or your country if you are ok with relocation. It is hard to start as a junior developer in another country, the same for remote jobs. Don't include these possibilities in your decision. Understand what kind of software development jobs are more suitable for you to start your career. Machine learning and AI is in very high demand and pays well, but it demands a very strong math and statistics knowledge and significantly more time of study to get the basics than web development for example. Check job boards for quantity and quality of companies hiring for junior roles. Don't stress about the intimidating list of requirements in these posts, they matter much less than you think. Find out how much companies are paying junior developers, but also senior developers. Understand that "senior" is a term for which each company has its own meaning. A good heuristic is to consider that the lower range of salaries companies are paying senior developers is how much you could be earning in 3 years and the upper range is how much you could be earning in 6 years. You end up with a very realistic view of your prospects. Do you see yourself progressing through this career satisfactorily?

Job performance in software development is about knowledge and work ethics. There is a lot to learn about software development. The body of knowledge grows constantly and fast. It may look intimidating like a crowd marching out of a stadium, so you have to keep moving with it. The worst reaction is paralysis. Are you in good terms with the idea that you will have to be learning new things for your job all the time? Forever? This should feel exciting for a software developer, so if you feel lazy just to think about it, software developing may not be for you. It derives from this that your work ethic should reflect the will and diligence to learn. Other than that, you will likely bring with you the same behavior on the other aspects of your work ethics, like commitment, time allocation, teamwork, and transparency. Your self-awareness on this topic will become more relevant when you start looking for jobs, something I am planning to write about in future posts. But it doesn't affect a lot your career decision to become a developer at this point.

If the suitable job opportunities you found look interesting and you see yourself capable of working hard and studying hard for several years to perform well in these jobs, then you have a good fit with the career of software development.

A decision based on joy and career fit

So, how do you know you will enjoy coding? You don't until you try it. My first contact with code happened a couple of years before my decision to go all-in. I was focused in founding a startup and I decided that learning to code would be useful in my endeavor. I didn't have the goal of becoming a developer at the time, I just wanted to know the very basics and be better prepared to communicate with actual developers that would build my product. I spent around 2 months studying part-time C# and .Net and loved every minute. I was building a very simple web app that would act as a medication organizer for people who take 5, 6 or more pills every day. I remember being eager for Monday to arrive. I never felt that so many times in any job. So, when October came, after failing my startup and being frustrated with marketing jobs in general, I knew I would enjoy being a developer.

And how do you know you will perform well in software development jobs? You can't possibly know before your first job, but there are signs. A great sign is if you can actually build something that works. While facing the huge, intimidating mountain of knowledge you don't understand, you still manage to find some of the small, more graspable rocks and actually build something with it. It counts less if you just follow command by command a detailed tutorial that shows each tiny step of the way. It counts more if you go further and ship a working prototype to be available on the web, hosted and deployed. Your code will be terrible, be sure of that. But if you can imagine, learn some tech, build something on top of things you are barely recognizing and it actually works! That's a good sign that you are capable of learning and overcoming obstacles to deliver value through software.

I built a few projects, like a to-do list with a creative UI, a search tool for animated gifs, a Facebook Messenger bot, a note-taking web app for personal development; a page that would show random, old, upvoted Hacker News comments. All of them with terrible code, no polishment to have a chance as a real product, but all of them working and deployed. This gave me a lot of confidence that I could deliver value to a company as a web developer. I could learn things and use this knowledge to build something else.

I knew I would enjoy coding every day, I knew I had a good chance of being a capable developer, I was ok with the prospect of having to study hard in order to keep growing, I didn't have any illusions about the kind of jobs that I would get (no glamorous job at Silicon Valley for me), I knew which jobs I would like to avoid. I discussed all of that with my wife and we decided that I would quit my job and start studying full time to become a web developer. I'm pretty sure it was the best professional decision of my life so far.

Coming next

My next post will be about the 7 months I was full-time studying web development. I will explain my belief that you shouldn't pay for anything until you are capable of deciding for yourself if that course/book/bootcamp is worth its price in knowledge. And discuss some things I didn't know I didn't know while studying by myself. And the next post after that will be about the search for my first job as a software developer.

If you want to be notified when the next posts come out (I don't have a defined schedule for that yet), please leave your email here:

Thank you for your time and I hope my experience and thoughts can help. If you want to contact me, and I would love to hear from you, use my github handler with gmail.

When I decided to become a software developer I quit my job to study full time. I was decided to learn to code enough to get my first job as a developer. My goal was to get a job in 4 months, it turned out to take 7. I studied using solely free, online resources. I believe this was one, among a few right choices that led me to successfully get a job - aside from luck, and I want to share what and how I studied. My intention is to help those who are really starting to learn to code from scratch, possibly coming from other professions and diverse background.

My personal choice and, in my opinion, a very good one for anyone who has never programmed before is to start with web development. Particularly frontend web development. There are a few reasons for that. At a basic level, it has an easier and simpler code than other domains. It offers instant feedback on the code you are writing; you write a few lines and just check how it looks on the screen. There are no hard choices to make at the beginning, you just have to go on and learn HTML, CSS, and Javascript. This quite evident beginning contrasts with the myriad of libraries and frameworks for web development that starts to pop out as you advance your knowledge. But, for starters, it is a fairly straightforward path. Also, even if you decide to move fairly quickly to backend development, this basic experience with frontend will be valuable. So, keep in mind I'm mostly talking web development in this text, even if sometimes it can apply to other domains.

How to study is worth some thought

Don't study too much what you should study, just start this journey with the first step. Although, an informed decision on which path should be your first step might help. The medium from where you learn the content can make easier or harder paths to follow. Before going into details on each medium, let me state that I firmly believe that you should not pay for any learning resource until you can decide for yourself if it is worth your money and time. Meaning that if you are indeed just beginning to learn to code and do not have a clue about what is software development, don't pay anyone to find out for you. This is particularly true if you can read in English, the language of most of the resources available on the internet.

The lure of paying for classes is the belief that they are a shortcut to knowledge. You rationalize that by paying it will be easier to learn because someone will be teaching you, it will be easier to create a habit of studying because there will be some sort of schedule, it will be easier to commit to it and don't quit because you have paid for it. It won't, it won't, it won't. You will learn more by teaching yourself, it is better to create your own study schedule based on your own needs and if your commitment derives solely from the guilty of spending money you will cut corners on your learning whenever you can and just do the minimum to justify the expense for yourself. Now back to how can you learn.

Books are a great source of knowledge. Just not for now. All the relevant books on software development require at least some degree of basic programming knowledge. Most of them will only have a real impact on you if you are already coding in a professional environment. When you begin to know the right questions to ask, some books will have the power to put you into a different level as a developer. While you are still learning the basic syntax of a language, there are more straightforward resources online.

Videos are popular among paid courses, which is surprising to me, as I just don't believe is the right medium to learn software development. In a video, it is common to have several minutes spent on preambles and explaining already familiar concepts and all of a sudden a new, important, complex concept is thrown at you. You missed it because you were annoyed or bored with what was before. You pause and go back. You don't know if the concept is better explored going forward or if you will be lost for the rest of the lesson. You go forward, you still don't quite get it. You are not sure if you should pause and google it to properly learn or trust the pedagogy of the course and just keep going. These situations happened to me all the time when I tried to learn by video. It may be just me and the fact that different people learn things in different ways, but now I ignore video as a learning resource.

Bootcamps are expensive. This alone made it out of the question for me. What it gets right is the full-time commitment to learning. Three months of full-time studying is much more productive than a year on nights and weekends. Learning to code demands a lot of your focus and attention. It is great if you can do it without being tired from a day of work. But if being able to quit your job and focus on studying full-time is a privilege, bootcamps seem like a luxury to me. I never tried one myself, so I can't go deeper into its pros and cons. I have the impression that if you are not doing it for the fallacious lures I mentioned before - a shortcut to knowledge, a crutch for habit creation or a guilty trap to commitment - then it might be a good experience. After you spent some time learning the basics by yourself, for free, of course. The "free-first principle" remains.

Code on the browser is how I call these interactive learning web platforms where you are given a lesson or a challenge on one side of the screen and an in-browser text editor on the other side ready to compile and run your code. This is how freeCodeCamp works. freeCodeCamp was the most important resource in my learning path and one that I wholeheartedly recommend. The method allows you to just start coding with immediate feedback. In minutes of starting, you will already have written code that works. You only need a browser and the bite-sized lessons are perfect for continuous and cumulative learning. It is for free, it has an active forum and you can get in touch with thousands of people going through the same things as you. I have no doubt that freeCodeCamp is the perfect first step for anyone wanting to learn web development from scratch.
It is up to you to decide how long to stick solely to freeCodeCamp. It took me about 2 months to complete the estimated 477 hours for the Front End Certificate. It is a good milestone to make a break and start with other resources.

Learn enough to start building. Start building before you learned enough to finish it.

A good rule of thumb to follow is: build a small, unambitious project with the tech you are learning, as soon as you learn enough to start building. The only way to know how to complete a project is to start your own. And finish it of course. When you try to build things you imagined is when it really starts clicking and all the information you had absorbed before transforms into knowledge. You start with tutorials, you improve with documentation.

Tutorials are great resources if you know how to use them. Usually, you find them on personal blogs or Github, they are made by individuals who are generous enough to share what they know in an organized way. They are a great way to start building something. The more detailed they are, the better. For a beginner is very valuable to read instructions on basic stuff, like what command to use on a terminal to install some library or framework. I like when they are even more basic, like explaining what a terminal is. Or even what is a text editor and mention some common ones for you to install. These fundamental preparations are usually taken for granted by senior developers, but they are very alien to beginners, especially those that are switching careers and do not have a background in Computer Science or spent some time coding fun stuff as teenagers. I remember spending some time googling what a terminal is.

The danger of tutorials is using them as an immutable recipe. They are a starting point to get you to that point where you can change things. As a rule, your final product should never look exactly the same as the tutorial's demo or screenshot. What to change is up to you and your preferences. The layout, the design, the UI, the use case, the name of functions and variables, the data structure, the way you deploy it. You may want to introduce your changes while you are building it - my preferred method - or complete the tutorial step by step, then edit it afterward to match your ideas. Anyway, make it your own project. Or else you will be only exercising on how to follow instructions, not on learning to code.

Finally, official documentation, the source you should always be learning from. The sooner you can get something useful from the official documentation of the tech you are using the better. For me, this tipping point came only after freeCodeCamp and a couple of tutorials. There is good and bad documentation, but it is a necessary skill to be able to read and learn from it no matter what. For HTML, CSS, and Javascript I consider Mozilla Development Network (MDN) Web Docs the best documentation out there. Then, each library or framework has its own. When you are always going back to check its documentation to learn how things work, that's when you know you are on the right path to master that particular technology.

How to ask Google

To be fair, this is more about how to frame your question in the same way someone already asked it at Stack Overflow, which is where you will end up 90% of the time. I only keep using Google because it is better at finding and presenting the results than Stack Overflow own search tool and because of those 10% of the cases when someone happened to write a blog post on the precise issue you are facing.

Before you google it, take some time to more precisely understand where you are stuck and what is that you are missing. Read any error message that you find. Make some changes in the code to try to narrow down where the error is happening. Learn how to use Chrome Dev Tools, the most accessible debugging tool. Inspect the HTML elements, check its CSS properties, read what is being printed at the console. Learn first how to use the console.log() command on your code to understand how your code is running, then evolve to the more sophisticated debugger; command. One important lesson: those hours stuck in a stupid mistake you just couldn't find and ended up to be a typo on an HTML tag or the lack of a ";" at the end of the line aren't "wasted time". It is training in debugging. Yes, this is a real skill, not something I made up to make you feel good about being lost for so much time. A skill you will use throughout all your career. It is a very frustrating training, for sure, but a useful one. Only that you must face it as part of the learning process. Meaning you should consciously try to get better and better at it. New approaches, new tools, new mistakes.

But sometimes, almost all of the time when you are beginning, no amount of lonely debugging will unstuck you. To quickly get to the stage where you know what is wrong, you just don't know the answer is part of the training. And that's the perfect time to google it. Of course, that's the ideal. "Debugging by multiple googling" is a thing when you don't even know what is broken (I think it is a thing at least... I do it). But the goal is to improve in debugging, to become more efficient. My google queries usually start with the tech I am working (css, javascript, react, ember...) and I phrase my doubt as a question. This is how it normally appears on Stack Overflow. It never crossed my mind that it would be any different, but I think is worth mention that googling in not "cheating", as I saw this concern appearing in beginner forums. Searching for answers is basically all you are going to do while learning. Finding someone with the same doubt that got their question answered online by someone with more experience is a great way to do it.

How to ask people

Sometimes, you are not sure what are your doubts. It is very common that you don't know what you don't know. Other times you just need a better explanation of a concept or need answers to some follow-up questions you have. These occasions the best thing to do is to talk personally with someone. An actual conversation with a more experienced developer about concepts and syntax and code. I was only able to do this when I got my first job as a web developer on a company with a particularly friendly and collaborative work environment among the developers. This advice probably does not help if you are learning alone, on your home computer, like I was. But I will talk about it anyway, so you are more prepared when you have access to other developers willing to help you in person.

Your stuck time should be measured in hours. If you are stuck for minutes, you still have homework to do debugging and searching before asking anyone to solve it for you. If you are stuck for days, you are not being productive anymore, not even as debugging training. This is a generalization, of course, but it helps you find the sweet spot between being too early and being too late, asking too much and asking too little. Another good proxy is checking if you have the right feeling when you think about asking someone for help. The right feeling, in this case, is that you feel you genuinely tried to find the answer by yourself and honestly think you won't find it alone. When you ask too early, the wrong feelings are of just being lazy and feeling how it would be much easier to someone else solve your problem for you. When you ask too late, the wrong feelings are of feeling shame about not knowing how to solve a problem without any help. If you don't feel lazy and don't feel ashamed of your ignorance either, you are probably asking for help at the right time. It is very easy to deceive yourself that, actually, it is not laziness or it is not exactly shame, just pragmatism or shyness. So always look for honest feedback from the people you are reaching for help. Also, not everyone has the kindness, patience or time to give you proper answers, so when it goes wrong, consider that before you think it is your fault.

Learn bit by bit and it will pile up

In the path of learning to code, you will be afraid. You will have crises of confidence, self-doubt, and discouragement. You will think that you will never be able to do the most basic jobs that developers do. But if you already made the decision to become a software developer, trust the process. Remember the reasons you made that decision, to begin with. Visualize your goal with it. Every little thing you learn matters. They eventually pile up and become something useful. That's why to keep building stuff while you learn is essential. You make the abstract more concrete. You can show it to yourself, to people that care about you, to strangers on online forums. On a path with no finish line, it is reassuring to look back and see how much you have already advanced.

Coming next

This post is a good description of how I spent the 7 months between starting to study web development full-time and getting my first job as a developer. Around month 4 was when I started to apply for jobs, so this 3-months period is the topic of my next post. Applying for jobs was not as new to me as software development, so I knew how to do a few things right and they worked. But I was also very lucky. I will try to distill the factors that made me lucky and possibly make it into actionable advice that others might apply to better prepare themselves. After that post, I plan to write about some things that I didn't know I didn't know while learning to code. Namely: code readability and maintainability, design patterns, architectural choices. I initially intended to make it part of this post, but I decided they are essentially different topics. It is good to know about these things now, but my ignorance then didn't stop me from having success in my first steps.

I still don't have a defined schedule for my posts, so if you want to be notified when the next posts come out, please leave your email here:

Thank you again for your time and I hope this was helpful to you. If you want to contact me, and I would love to hear from you, use my github handler with gmail.

After 4 months studying web development full-time I decided I knew enough of the basics to start looking for a job as a junior web developer. It took me 3 months of job hunting to get hired. During this period I applied to 10 positions and my time was grossly divided like this: 60% of the time still studying, 20% looking for good jobs, 20% applying to them. I know that only 10 applications sound too few for such period, but I believe that fewer applications actually improve your odds of being hired in a given time period. There is a lot of luck involved in getting a job, but regarding what is not luck, I want to share what I did when looking for jobs, applying for jobs and interviewing.

Learn how to be a good developer, not a good candidate. That said...

When I stated at a public forum (Hacker News) that I had just started to study software development and my goal was to get hired in 4 months, one fairly upvoted comment was that it was "not possible unless I fake my way in". Obviously, I ignored the "not possible" part as it was just a dismissive blank statement, but I was surprised for a moment that someone could fake their way in a job as a developer. I thought one couldn't fake how to code but then realized that, like any profession, people could abuse interviewing skills and lack of ethics to get hired and stay in jobs they can not perform. To go this way is obviously a poor, unfulfilling, short-sighted choice. This is just to say that I will focus on skills that are applying mostly to the hiring processes of tech companies, sometimes orthogonal to coding skills. But remember that you still should spend most of your time studying and practicing the craft of software development, not interviewing skills. That said, to build your career, you have to land the first job.

One of the choices that might increase your chances to get lucky and land a job is the tech you study. Study what is hot, but not what is hype. When you are a hired professional you should choose the best tech for the job at hand, no matter what is hot or hype. But when you are starting, you choose the tech that is asked at the most job positions, simple as that. In the frontend world, for example, there is no doubt that a beginner trying to be hired should choose React. Just take a look at the latest Who is hiring thread at Hacker News, for example. A text search for React and you get 46 results. VueJS is a new framework, a lot of praise from developers and it looks the most hyped tech right now. But it is "only" mentioned 10 times in the thread. Ember is a very mature and solid framework, ready for production in professional environments. But it has 7 mentions. Angular has 16, a little better, but still no match for React right now. So at least one project using React in your portfolio is a great asset at a beginner's resume. Just don't forget that a good foundation in Javascript precedes any dive into the world of frontend frameworks.

Another part of the preparation before you even start applying is your portfolio. Every junior developer should have a few public projects to showcase their skills. The projects don't have to be awesome and the code can be a mess, as long as they improve from one project to another. Your more recent projects should be better built and more evidenced in your resume. But don't delete your early projects, no matter how bad the code and the end result are. Those senior developers evaluating you want to find candidates that can learn and improve. They know everyone's first projects are terrible.

What to look for when you are looking for a job

Companies that are serious about hiring. There are a lot of job ads out there that no one that cares is actually reading the applications. Look for good signs that a job ad is for real. The description of the company and of the job should be well written, with relevant technical information that you can tell was detailed by a developer. It is preferable when the method of contact an individual email, not a standard form. This excludes most of the huge companies, that get thousands of applications for any job position. That's why networking is a much more effective path to get hired at huge companies.

One thing that is a blessing for junior developers is when the hiring process starts with a code challenge. That means that the company actually cares about the hiring process, that some software developer will be part of the decision to hire from the beginning and that almost for sure you will get a response, Some few times even a feedback on your code. More senior developers usually don't like code challenges because they are time-consuming, not enough to evaluate in depth high skills and they have more real work to show. But for junior developers just beginning it is an opportunity to learn while doing, get valuable feedback and stand out for your hard work, as these jobs filter out lazy applicants. You will have less competition in any job that asks candidates to build something as a first step. This was actually my main criteria when searching for open positions, find the ones with a code challenge.

Find a job/company that suits you, so you don't have to pretend you are a good fit. This is not only about the "culture" of a company, I am of the opinion that you can adapt to almost any corporate culture if you have a nice boss and nice colleagues. But it is mostly about the job description. There are a lot of shitty jobs in web development. A typical example is some advertising agencies where the only task of a frontend developer is to transform graphic design templates into HTML and CSS. You will work alone, almost no Javascript, usually no senior developer to mentor or teach you and you will be treated as a disposable asset with no saying in anything that matters to the business. Sure, there are desperate times when one should accept worse conditions, but if you can, run away. Good jobs might also be filtered out for lack of a good fit. If you are planning to be a frontend developer more dedicated to the UX and design area of the field, don't apply for jobs looking for a full-stack more inclined to the back-end side of things.

Care about each application as it was the last one

The main perk of spending more time looking for and filtering the right job positions is that you can now spend more time on each application. Because there are just a few of them. Never do just the bare minimum to apply. You will end up being discarded by companies that really evaluate an application and be selected by the ones that don't care much about who is applying, they just need to fill a vacancy (which usually means it is a shitty job). Again, companies that ask for code challenges are expecting hard work. It is the reason they ask for it in the first place. A half-baked application will only waste your time and the chance at a good job. Back to my main mantra of only applying to a few selected jobs: only apply for those that you are motivated enough to put the effort.

Interview preparation and attitude

Interviewers of junior positions are always looking for three things: basic coding skills, ability to learn things and ability to communicate professionally. The coding skills assessment is usually based on the code challenge or your portfolio. Be prepared to answer questions about those. Review the code of your projects and, more important, the decisions you made when building it. Why use some tech, the doubts you had while building it. Interviewers will use these questions to check if you indeed build the things you say you built, but also to see if you care about the craft of software development. It matters more than you think to leave a good impression that you care about your code.

Your ability to learn things will be assessed through your curiosity, your desire and diligence to improve, your awareness that a software developer will be learning forever. It is important that you let your curiosity and eagerness to learn new things show in the interview. Another measure that interviewers will use is what have you studied and built so far against the time you took to do it. This is a reminder that slacking and procrastination while learning to code is a cardinal sin. Try the most to be really intensive in the hours you designated to study software development. Learn things, build things, create a body of work that you can show and impress people on how fast you get to that level. Even if it is still a basic level.

Professional communication is all about confidence and practice. Some people can fake confidence and some people are more natural as communicators. But you probably aren't one those people. Your confidence should ideally come from your acquired knowledge. That's why it is important to study for your job interview. Study your code, study the job description, study the company product, study the company culture. For each interview, spend one or two hours reviewing all of that. For each one. Don't be lazy. And practice. Practice with someone or in front of the mirror how to answer some common topics. Like explaining your last project and your code decisions. Or the classic "Why are you a good fit for this position?". It is common to become too self-aware and awkward during these practices, but they help. A lot. Don't avoid doing it because you feel stupid. You looked stupid too while learning to ride a bicycle. Deal with it. But don't practice only for the interview. Practice explaining tech concepts to non-tech people and product concepts to tech people. It takes some effort to properly communicate, if you realize it and care about it, you will inevitably get better.

Learn what the company's software development team values. Stalking mode. Find the developers and the CTO on LinkedIn, Twitter, their blogs. Read what they write about, what they care about regarding tech, the advice they give about software. You will probably come across a few common concepts they follow. Like Test Driven Development. Read about these concepts, but don't memorize the dogmas, understand the reasons why some people consider it a dogma. Create your own critical opinion about it. Don't be arrogant believing you have it all figured out, but don't be a sheep repeating what you read online. The idea is not necessarily to show the interviewer that you have the same opinion. But to show you know about that concept and have considerate thoughts about it.

Learn what you are good at. Learn what you are bad at. Mention both of them in the interview. I was very self-aware of my strengths: communication, work/study ethic, background in marketing (relevant as I was applying to be a web developer, mostly at startups) and my weaknesses: total lack of CS background (meaning I lack fundamental concepts in my education, like the architecture and design patterns basics), no experience as a developer in a professional environment (never worked on a code project within a team, no code reviews), very very basic Git knowledge. I was able to show how much value I could deliver to the company through my strengths and how self-aware and eager I was to learn and fix my weaknesses.

What not to care about, what to run away from

Hiring is broken, but it is not up to you to fix it. Most of the time you won't know why you got rejected. Most of the time the people that rejected you won't know either, even if they think they do. All hiring process in the world is a mess full of random decisions and all kind of bias. There are a lot of legitimate reasons why you never get an honest, straightforward feedback from companies too. Someday you might be in the position to try to fix this in your company. But not now, not as a candidate. Accept that you will never know why you got rejected or rationalize some reason that doesn't make you too emotional. And move on to the next application. Be pragmatic.

People will undervalue you. Chances are not all interviewers will be nice. On a promising application for a cool job, I got a call from the founder. He said something in the lines of "You know, you have to understand that you are competing with a lot of young guys who are coding since they are twelve. You have a lot of catch up to do. You have to expect an intern salary and even so work harder to show you can become a good developer. Because I'm not sure you can." Maybe he was just using some shitty negotiation technique to hire me on a low salary, maybe it was ageism, maybe he thought I was delusional on my aspirations and decided to give me a lecture to be more down to earth. Whether he was stingy, mean or patronizing, it was definitely a place that I wanted distance. Learn how to identify places where people are not nice. Maybe it is just me and I shouldn't be advising people to follow such a subjective criteria. But I use "niceness" as the first and most important criteria to choose which people I want to be around and it has served me well all my life.

Coming next

This is a distilled advice from my experience getting my first job as a developer. I was very lucky to be hired by a great company with a great environment for a junior developer. And that's when my real education in software development begun. There is a lot you don't know about software when you are learning "just" to code. Most of it you learn by something called Code Review. Other developers take a look at the code that you want to add to a project, analyze it and criticize it about things you had never considered when you were just building amateur projects for your junior developer's portfolio. A new world of knowledge that I had to gain opened to me through the gates of Code Reviews. The next post will the completely dedicated to this process of professional software development.

I have no defined schedule for my posts, so if you want to be notified when the next posts come out, please leave your email here:

Thank you for your time and I hope this was helpful to you. If you want to contact me, use my github handler at gmail.

I can point exactly at what made the most impact in my education at software development: code reviews. It is obvious to me that what made me progress from learning to code to learning software development is being part of a team with good code review processes. I now believe code reviews are such a big deal that, from now on, I will capitalize all of them.

Code Reviews are so powerful as an educational tool because they are quality feedback from peers (usually) familiar with the context and that have incentives to keep the quality of the code base high. The feedback is very specific to the exact lines you wrote. And allows for demonstration and debate of theoretical concepts applied to a very concrete and specific situation.

Code Review is the single best educational resource that only a professional environment can offer (I'm planning to take a shot at changing this, I will explain better at the end of the post). But any great resource can be misused, neglected or misdirected. I want to share some thoughts from a junior developer's perspective so senior developers can develop more empathy when reviewing juniors. And also so junior developers know better on what to look for when colleagues are reviewing their code. I am just beginning (only about 6 months at my first job as a dev), so I can't be confident that this would apply to everyone in every company. I am just sharing some impressions from my experience so far.

Styling and formatting matters, but it is basically a one-time lesson

Juniors usually don't know how important standards are to make code readable by other developers. It is necessary to take the time to explain the reasons why and share the standards used by the team. It's an easy lesson, but must not be neglected. Once explained, the enforcement must be automatic. One shouldn't have to waste mental effort on something that is supposed to be just blindly following agreed rules. A linter plugin at the code editor is usually enough.

Code Review is collaboration

The crux of getting all the benefits of the Code Review as an educational process was to correctly internalize a new mindset regarding education: it is all about learning as a team. It is natural but harmful for junior developers to see senior developers reviewing their code as teachers grading their exams. That's a wrong perception that must be fixed from start. Juniors have to understand that they are being corrected without being judged. They are being questioned without being mistrusted. They are doing stupid mistakes without being stupid. I am not sure how common or rare it is, but I was lucky enough to find a company where everyone is helping everyone, not trying to prove who is better or using Code Reviews as a platform for office politics.

The team, not the junior developers themselves, has the onus to create this welcoming environment. It is in benefit of everyone involved - the juniors, the rest of the team and the company - that junior developers be very comfortable and safe being reviewed and also incentivized to review other's code. The goals of a team onboarding a junior developer should be: minimize the anxiety of opening a PR, provide a safe environment for making mistakes - e.g. no production database writing access, and be sure that the junior understand the mistakes they made. The goals as a junior developer entering a team should be: never make the same stupid mistake twice, create software that delivers real value, and be humble to learn from others that know better than you. Being defensive when being reviewed ruins it for everyone.

A boost in the learning comes from taking different roles in the process. I learned a lot from being reviewed, but also from reviewing other junior developers, reviewing senior developers and even reading senior-senior reviews. As long as I took the time to read and understand some of the more sophisticated code and commentaries. Everyone has different angles to offer and everyone has a few blind spots too. Code Reviews are always a teamwork with rotating roles.

Code Reviews are part of the job, not a favor or luxury

No matter who wrote the code, every line of code is important and deserves attention. Part of the process is to check every line for every kind of bugs and improvements. At the same time, if everything is good, it is ok to just approve it (and maybe leave a few compliments). No need to be picky about something just to keep the appearances that you indeed reviewed it. The risk of neglecting to thoroughly review a code is more salient in the two extremes: when a junior is writing a very simple and basic task that has "no way" to mess up or when a very experienced and admired developer is writing any code and people just assume they are right. Reviewing code should be author-agnostic.

Code Review should have steps and structure. That's a particular topic that I need significant improvement. I usually review reading the code in an unstructured way and almost random order. My learning list includes talking to some developers and asking them how they do Code Reviews. Possibly creating my own checklist, like an attack plan. With these steps clear in my mind, I will also effectively internalize what is important in my own code while I am writing it.

Tests deserve special attention. Tests are even more conceptual than regular coding. When you code a feature, if it works, it works. It might have all sort of spaghetti code and technical debt and hidden bugs, but you start from something that is delivering some value at least. And the intended goal of the code usually is obvious. With tests, there is no such thing as "it works" and the intended goal of a test is exactly what must be reviewed. Tests that pass only deliver any value if they are testing the right things the right way. What are the right things and how is the right way are definitely not easy to grasp as a junior developer. It is still something I consider among my weaknesses currently. When spotting a problem in a test code, it is good to take more time than usual to write the comments in the PR. Short sentences might be enough to show that a variable name is not ideal. But to properly explain why a test needs changes, some more verbosity is welcome. Even Hemingway sometimes used longer sentences.

You gotta help me help you

I learned that the Code Review should be on your mind as soon as you start writing the first lines of code. It should not be an afterthought once you finished the first version of your task. Two things matter most: planning deploys optimizing for short pull requests and putting serious effort in descriptions.

Big Pull Requests are the worst. The more files and lines of code changed in a PR, the worst will be the review you get. It was particularly hard for me to learn how to properly separate the code I am writing in coherent modules that could be reviewed independently. But it is something that the whole team must have conviction. One trick that helps is to accept the idea that some merged code won't deliver value at first but are planned and robust enough to be "deployable". Pull requests should have up to a maximum of 193 lines changed. Of course, any number here would be arbitrary, so I just wanted to stress that with a random number. But that's in the same ballpark and it is useful to keep the idea that if it is over that is probably too long. Keep in mind that the more time a developer spends reading the code the less focused they will be. And it is a waste of everyone's time, unhelpful and usually harmful to get a Code Review from someone who isn't properly focused on the task.

I began to believe that commit messages and PR descriptions are a high form of literature. Reviewers need context. In my company, we do not include comments in the code. So, aside from the code speaking for itself, the commit messages and PR descriptions are essential documentation of what is happening in each part of the code. The commit messages must be concise, yet make the objective of that commit clear. An extra bonus is that this practice nudges you to have very clearly in your head what is the purpose of every commit. The PR descriptions must necessarily include three things: why it was created, what is being added and what the end result is. Always starts with why that code must be merged - what problem it solves, but also how it affects written and future code. Then what was effectively done - the files and features you are changing and creating, a topical summary of what was added and removed. Finally, how it is working. In my case, as a frontend developer, it often includes screenshots or animated GIFs showing how the feature works on the screen. Putting effort in these written communication skills paid off as I made easier for my reviewers understand what I did and get an extra time to educate me in return.

Educational Code Reviews

To summarize what worked in my experience, these are the necessary factors to make the Code Review process a great learning tool in a team: a supportive environment, reviewers that are not teachers, junior developers being reviewed and reviewing, well-thought-out and well documented PRs. A team of developers working with you that accommodate all that is (I would guess) commonly found in professional environments, but virtually inexistent for people still learning to code. That's a problem I want to give a shot at solving.

I am starting a project to provide Code Reviews to people learning to code. If you are starting in the path of software development, already building something with the code open at Github, and not yet working as a software developer, you are in the same situation I was a few months ago. And for whom I am starting this project. If you are interested in getting code reviews for your project, please fill the form below to get more information.

UPDATE: the experiment failed. With just three interested people (each using a different programming language), it wasn't possible to create one group for code reviews.

Coming next

I wanted to dedicate a whole post to Code Reviews as a learning tool, but there a ton of things that you need to learn and can't do that through Code Reviews. Like other languages, new libraries and framework, deep dive in Computer Science concepts and the list go on. In my next post, I will try to consider the difficulties and possible solutions to keep studying software development while having a day job. It will be mostly about time management and smart choice of topics.

As I don't know when I will publish that, if you want to be notified when the next posts come out, please leave your email below.

Note: this is a different list of the form above. If you are interested in my Code Review project and want to be notified of my next posts, please fill both forms.

Thank you for your time and I hope this was helpful to you. If you want to contact me, use my github handler at gmail.

As a 38-year-old becoming a software developer, I knew my previous work experience in unrelated fields would help me in my new career. I was just not exactly sure how. Now I know clear communication and good writing skills are how. When I started learning to code I kept reading that a good developer needed good communication skills, but it was always hard to imagine exactly why and where it was needed. Now I see clearly how a better code is written when you write good function and variable names, good test descriptions, good commit messages, good pull requests descriptions, good user stories and specifications. And these are only the more code-related, written applications of this skill. There are still written and oral communication challenges when discovering demands, deciding prioritization and presenting features with product owners, managers, and non-tech colleagues. In this short term as a web developer, I learned a little about the importance and application of communication for software development. I think personal interest and professional experience taught me a few things that are extremely useful in day-to-day activities as a programmer. I will share some of these insights, focusing specifically on writing as an effective tool for communication, rather than the more broad and complex subject of communication itself.

It is hard to write consistently well. It is easy not to write consistently poorly.

Communication, particularly in the written form, is a skill that I care about. Caring is enough to improve anyone's writing skills to the point when it is one of your strengths, not weakness. There is no secret or steep learning curve if your goal is to avoid poor communication in a professional environment. I have no illusions that this is where I stand as a "writer": I can avoid poor written communication. If the goal is to become a great writer, consistently producing great pieces of text, whatever the context, then it is hard. You will need an order of magnitude more hard work and a better teacher than me. But effective communication through writing is achievable. Anyone who cares can transform communication from an obstacle that gets in the way of your code to a tool that helps you develop software.

I am not saying it lightly that is important to care. The implicit and explicit reasons a professional has to not care about communication are, at once, cause and justification for their poor communication. Not caring about your writing comes in two flavors: conscious neglect and unconscious neglect. The conscious way usually comes with some arrogance. That explaining some concept in proper words is beneath you. That somehow your code speaks for itself. That you are so sure you are right in what you are doing that you do not even bother to explain why. But people that consciously do not care about their writing are also not reading this. So I won't spend much time on this case.

Now, to unconsciously neglect your writing is the most common way to do it. You have the idea in your head, you write it in an automatic way that you barely process through your brain and then consider the task done and move on. You assume that your idea is reflected in those words as, obviously, you wrote those words to express that idea. What could go wrong? A lot. What you neglect is everything that you have when writing that your readers lack when reading. Things like: hidden assumptions that fundament your idea, the context where those ideas are applied, the exact meaning you are using for ambiguous words, the goal you want to achieve with that text, the access to all other texts that help to define the meaning of your message, the understanding of the right tone and intention that one should read those words. These things are only noticed if you pay attention. But these oversights can easily be avoided by following a simple process:

  1. Think about the message before you write it.

  2. Think about the person while you write it.

  3. Rewrite it.

Before you write: think about the message

It is important to think through the message you want to pass and have it clear in your mind. It helps to write it down in an ordered list, prioritizing the most important topics. There is usually a core message that prompts you to write that text. That should be clear for anyone reading it. The message you want to pass doesn't have to be just hard facts, like informing someone that a feature was deployed. Sometimes the core message of your communication is to transmit something intangible like a sense of urgency for a task while keeping it polite and not look demanding.

To transmit abstract concepts is tricky and when it involves subjectivity, like feelings and perceptions, it comes full of dangers. The danger of being too subtle, the danger of being passive-aggressive, the danger of being rude. That's why I always prefer to check that my intentions are candid and transparent. But with written communication, intention only is seldom enough. Thus the power of thoroughly thinking your message beforehand and distilling it to its essence. Back to the example above, if you took the time to understand that your core message is to transmit your sense of urgency - not to complain, not to demand, not to intrude - then you already have the right word to use. And your text might look something like this: "Regarding that task, I'd just like to let you know that it is of high urgency for me because of its impact in this other task I have with my team. I don't mean to interfere with your work process or sound demanding, just letting you know so we are on the same page. Thanks!"

I used generic terms, but a better phrasing here would include exactly how one task impact another. This would signal that you want to convince the reader that this is important, not just tell them. So the second topic you want to include in your message is to explain why your sense of urgency is justified. Put that on your list.
Also, for sensitive topics like this, it helps if there is enough informality in your communication that you can add some jest or emoticons to set the right tone. A ":)" at the end would help set a light, not demanding tone.
Last thing about this example: it is certainly the wrong wording. It is impossible to set the right tone if the reader is imaginary. If you read this and it sounded not exactly right, a good exercise is to rewrite just how you would be comfortable reading it.

While you are writing: think about the person

As a writer, you are serving the reader. As we are not talking about literary writing, you must avoid ambiguity and prioritize content over style. The person who will read your text is the dictator of every word you write. You should choose the synonym the reader will most likely recognize, you should know which concepts the reader is and isn't familiar with, you should know where the reader will read it and when. You should exercise your empathy, anticipating possible doubts, reasons for confusion and counter-arguments. When writing, you should think as your reader.

A great start, for every communication, is to establish common ground, guarantee that you and your reader are on the same page. This is actually very easy, just explicitly state what you are talking about in that text at the very beginning. This is paramount in emails. The first thing you write is what that email is all about. A feature announcement, a complaint, an FYI regarding a specific topic, a request for a favor. One very objective and contextualizing line. This is particularly important in communication channels that do not provide context by themselves like email and messaging apps. I personally have the practice of repeating this context-giver one-liner on emails as both the email subject and the content's first line, as people have different practices on reading or not email subjects. On Slack, I always add it just after the initial greeting, in the very same line. By comparison, a Pull Request description already inherits the context for things like the repository, the branch, even the person who is creating it. Commonly used naming patterns (like feature/...) also help. So you can start with the core message (i.e. the feature you are developing) in the title. Still, it is a practice in my team to begin the PR description with a "Why?" section, that explains why that feature is being created and the business needs behind it.
It is not by chance that Pull Requests have so much more emphasis in context. Some of its readers are in the future. From your future self to future developers that your company not even hired yet and won't get to know you personally. So all the context you have just for living in the present time have to be registered in written form.

Another kind of challenge comes when you have to communicate technical topics to non-technical people. There is a very thin line between educating and patronizing, between explaining by analogies and dumbing down, between using proper technical terms and obfuscating. A good practice is to decide beforehand what you want and what you don't want to explain. You might decide it's important to explain what a deploy is but refrain from going deeper about your company's continuous deployment practices. If you think it will be useful for the reader to learn about a particular topic, take some time to explain it. It will spread the knowledge and maybe even save you some time in the future when communicating with the same person. A personal choice is that I always aim at using words and concepts a little bit more advanced to what I expect my reader to know. This way, if I underestimated the reader's knowledge, I rarely miss that much that is patronizing. And if I overestimated it, I just have to explain a little further. On average, I am pushing the reader's knowledge a little bit wider.

After you wrote it: re-read it thinking about the person and the message, and rewrite it

My personal heuristic is to only consider an important text completed once I re-read it from the first to the last line and don't find a single comma I want to change. A less strict rule, applied to less important texts, is to consider it completed once I don't make any changes to the meaning of a sentence while re-reading. In any case, this algorithm requires at least one complete reading after I finished writing it. No matter how much you planned your message, no matter how much conscious you were about the reader, your focus when first writing is (and should be!) on putting your idea on the paper. There is a lot on your mind and you have to save it somewhere before taking the time to improve it.

The idea in your head is like the beautiful, complete picture at the box of a jigsaw puzzle. Your first draft is the moment you open the box and throw all the puzzle pieces on the table. Only then starts the real work of transforming the mess you created on the image you have in your head. The principle remains the same while rewriting: think about the message and the person who will read.

There are a lot of possible things to fix that you usually get while re-reading. The core concept is not clear. A part of the message is missing. The tone is not right according to your own intentions. A paragraph is not coherent by itself. There are words the reader will probably don't understand. A chosen synonym is not exactly right in its meaning. There are repeated words. There are missing words. There are too many words. Typos. Grammatical and orthographic errors. A sentence is too long (thus hard to parse). The formatting is obscuring the understanding. A word, sentence or paragraph meaning is ambiguous. These are bugs preventing the characters you wrote to achieve the desired effect.

Things that do not seem to matter, but do

Formatting. A rule of thumb I use for emails is to always skip a line between paragraphs. A paragraph should encapsulate a unique concept, maintaining coherence and completeness in itself. So it is important for the reader to visually notice this separation of topics. I use a lot the expedient of bold and italic. It is easy to abuse these features, but it may be very helpful in properly transmitting a message with the right tone, focus, and meaning. I use both italics and quotation marks to make it obvious when I am quoting someone else. I use bold when I want to emphasize a keyword that would help someone that is just skimming the text. That's the case with this paragraph. The topic header implies a list - "Things that...". I wanted to present that list in a skimmable way, without creating another level of subheaders that would disobey the rest of this text pattern. So I started the paragraph with a one-word sentence and made it bold.
Another great feature for developers is Markdown styling. Wherever it is available, you should learn all rules and use it whenever you can. Of course, there are ways to abuse it, but it is usually very safe to use. As every code sample should be marked as code, every list of bullet points should be marked as such.

Order. The order you present your message matters a lot. The email rule to objectively provide the context in the subject and the first line is an example of this. Never create suspense for your core message. It is easy to illude yourself that you will create the atmosphere before dropping the bomb that will impress everyone that reads it. It is more likely that you will annoy them and most people will never get to the punchline and just skip it. Even if you have the talent for it, professional communication is not the place for Back Mirror plot devices.
But if the core message you have to pass is something completely new for the readers, there is the risk of getting too fast to it and confusing everyone. A general rule that helps to properly order your text is to always begin with the familiar. Your text, your paragraphs, your sentences should begin with ideas that the reader is already familiar. They may be familiar because of some knowledge you assume they have or familiar because you introduced the concept in an earlier paragraph. The exception comes from the need to balance this with the no-suspense rule: never leave essential information only at the end of the text. If the core message you want to communicate is also the most alien concept to the reader, you can start with it, even if the reader feels confused at first. But also keep it short, to minimize confusion, acknowledge it is something new and then move on to properly explain the concept through the rule of beginning from familiar to novelty.

Word choice. Synonyms are not strictly equal among themselves. The language is more organic, less logic than code. Every word choice brings its own nuances in meaning. A word's meaning itself varies in time and space. Always aim for the word that is the right fit for the context: it can't be too formal, or too informal, too snob, too vulgar. Also, aim for the word that is most familiar to the reader. You want the reader get your message, not be distracted by your vocabulary. But these goals have a limit you can't cross: never sacrifice the meaning. If you have the word that conveys the exact concept you want to pass, keep it. If necessary, include more context and explanation so that new word does not add confusion. You do that properly and you just taught the reader a new word that made them perfectly capture the message you were trying to communicate. Every word counts.

Sentence structure. It is a good practice to use the active voice - i.e. when a subject does something, instead of something being done by a subject - in your sentences. It is easier for the reader to parse it and it brings more objectivity in the way you transmit a message. But there are a few important exceptions to this rule of thumb. When you are following the principle of ordering your sentence from more familiar to less familiar information, the more familiar information might not be the subject of your sentence. For example: "I didn't want to use a new framework for this project. This decision was made by our CTO." The second sentence becomes more clear when you start by referring the information presented in the first one. It makes a smoother transition from one sentence to another.
Another exception is when you have no interest in giving importance to the subject of the sentence. For example: "Our team is composed of four developers and one product manager. The name of our team is Go Horse Squad and our domain is growth, but only the beginning of the sales funnel. The end of the funnel is handled by another squad." The last sentence is in passive voice because you are presenting your team to someone and there is no reason to get into details about another team. It could be confusing to the reader. In this case, it also follows the principle of beginning with the familiar information - the sales funnel - and end with the new info - there is another squad.
Also, passive voice is the only choice if you don't want to be explicit about who is the subject of the sentence. For example: "The decision was made, now we have to deal with it." This sentence is adequate if said decision is a sensitive topic and you want to refrain from an argument about who made it and their reasons. You want to transmit the sense that there is nothing to be done and you all must be pragmatic about it. If it was rephrased as "The CTO made the decision, now we have to deal with it." it is a completely new meaning. The impression the reader gets now is that the CTO is the focus of your message, implying that you are criticizing his decision and you are dealing with its consequences with more grudge than pragmatism.

Communication feedback is subtle and unassuming. Learn to recognize it

Good professional writing is easy to learn, it only takes deliberate practice. But how do you tell if you are improving? This one part of the learning process is not as straightforward as the rest. Written communication is usually asynchronous and rarely you get spontaneous feedback on your communication skills. Mostly because the message you want to pass is more important than how you pass it. So you have to look for any feedback about what you communicated and distill it to what is actually a feedback on how you communicated it.

The most obvious case is when people criticize the tone of your writing. If people say you were too rude, demanding or harsh on your email, and you had not the intention to be any of those things, then this is a feedback on your communication skills. When the tone is more annoying than offensive it is harder to get this feedback though. If you are too prolix, makes too many jokes or use too many emoticons in your emails, you will only find out if you develop your self-awareness, because people tend to not explicitly say those things to your face. Or you can ask for blunt feedback from someone with enough trust to be honest.

One topic that asking for feedback doesn't help much is the most important one: if your message was understood. People can only answer based on the message they understood and if they misunderstood it, they still can say it was perfectly clear to them. Only that what was clear was the wrong thing. How to find out? You have to find clues in what people say back to you.
When someone asks something that was already in your first text, this is a feedback on your communication skills. It is rude to say something like "As I said before, ..." and go on repeating the same thing. Take the opportunity to re-read how you wrote the first time and change it to improve clarity. When someone makes evident that they didn't read it to the end, the order you wrote could be improved, or your text was too long, or it was not a smooth reading.

Of course, all these misconceptions by the readers could be their fault, not yours. Communication has two sides and only one side is needed to ruin it. But it is more productive to always assume the fail is on your side. You failed to properly communicate something and that opened room for the other part misunderstanding it. This doesn't have to be true to be useful. You may practice defensive writing, thinking about all the ways the reader could misunderstand your text and avoiding them. You have to assume good faith by the reader on wanting to get it right. If that's not the case, you need an extremely defensive writing that is the specialty of lawyers. And the legalese language used by lawyers is the opposite of effective communication in regular professional environments. So if you have a boss or colleague that always willingly misrepresent what you write, you have a bigger problem than your writing skills.

Sign my newsletter for regular writing tips

I will continue to write about varied topics about becoming a software developer in this blog. But, with this post as the kick-off, I am starting a new venture: a newsletter focused on giving written communications tips to software developers.

As this is the topic that I am most able to help the other developers in my company, I thought about making it a side-project and help more people. Fortunately, I stumbled upon a great new service that might be the perfect way to do that. Substack is a startup that offers a platform for content creators to publish (optionally) paid newsletters. I will start with a free newsletter of course, but if it gets traction and I decide to invest more regular time in creating content, it offers an easy way to monetize it through a business model more suited to my personal preferences than ads.

So, if you are interested in getting more tips about effective written communication for software developers, please subscribe to my newsletter here:

Subscribe at Writing for Developers Newsletter

Thank you for your time and I hope this was helpful to you. If you want to contact me, use my github handler at gmail.