Learning to program is a long journey, and it can take years of constant effort to become good at it.
When I started writing my first lines of code, I felt super excited that I could make a machine do things. Granted, they were very simple things, but I felt I could achieve anything with this cool new skill. After a while, I started to notice that the more I knew, the more confused I felt. Lots of questions started to pop up every time I sat down to write code, and not only technical questions but also things like:
Which programming language should I focus on?
What areas should I learn, web development, embedded systems, mobile development?
How can I be sure the code I am writing is good? Am I writing trash code?
And many others.
I wanted to share some of the things I've learned in the last years in a series of articles. Yes, these articles will not answer questions like what career path is right for you, or which programming language you should learn, only you can answer them. They are a collection of the many things I wish I had known when I began my journey as a programmer.
I hope these lessons will be as useful for you as they have been for me.
Principles are more important than technologies
Yes, you need to learn a programming language to land a job in software development, it's an important tool. And yes, usually you also need to be proficient with a specific framework or library to land a specific job, that's the way things are.
The thing is, while this is important practical knowledge, it's not the most important thing to focus on. Instead of chasing the latest framework or collecting programming languages, you should focus on the main principles of software engineering and computer science. Things like:
- Data structures and algorithms.
- Object-oriented design and design patterns(or equivalents in your favorite paradigm).
- Ability to manage complexity and abstraction.
- Caching and memory hierarchies.
- Computer networks.
- Software quality, and how to write clear, readable code.
- Requirement engineering and software documentation skills.
- Test writing.
Prioritizing this type of knowledge has many advantages. First, computers haven't changed that much in the last decades, and while your favorite framework might go out of fashion next month, the observer pattern will continue to be useful for years. Second, these skills will be helpful independent of your area of focus. Understanding how computers work and how to craft great software is important, it doesn't matter if you write code for a washing machine or a mainframe.
So, go grab a design patterns book or read about code quality, it will do wonders for your career.
Cultivate people skills
Being able to communicate in a clear way is the most important skill a software developer can have. The fact that we work with computers and machines all the time gives off the impression that we rarely, if ever, deal with other human beings. On top of that, you get the way programmers are portrayed in media: antisocial dudes who would rather have a root canal than having to talk to a colleague.
In reality, we are not different from any other professionals. We still go to lots of meetings, chat with our colleagues and enjoy spending time with other people. In a similar way, the ability to communicate plays a very important role in our daily activities. Sooner or later you will need to communicate with colleagues, clients, and management. For making the most out of these conversations, you need to learn how to listen and how to properly structure your thoughts using words.
Humans are at the core of software development. After a couple of years, you come to realize that the main source of complexity in this profession is the human factor, which reminds me of the following point.
You are not paid to write code, you are paid to solve other people's problems
This is something that I've been repeating for a while: your job is not writing code, your job is providing value.
Sometimes you provide value in the form of writing a new software product that solves a person's problem. Other times, you get a request for a new feature and write it into an already existing software solution. Because this is what we often do, it's easy to lose the main goal from perspective: solving another person's problem.
No matter what you do in the value pipeline, your job exists because it solves another person's problem. If you work in application development, you create products for users. If you test software, you provide a service to development and your end users by ensuring quality. If your job is in operations, you ensure users can access their software. Think about it, there is no IT job whose final goal is not serving people.
It's important not to lose this from perspective for two main reasons:
1. Do you really need to write that line?
Sometimes you don't need to write a single line of code to provide value. Can you achieve the same impact by just changing the configuration settings? Is there a way to help your users without a new class? If those are viable solutions, go for them.
2. Listen to your users
The industry is full of well-written software products that solve the wrong problem or solve it in the wrong way. How can so much thought go into writing a product divorced from the real needs of the users? Well, for starters, ask yourself when the last time was you talked to the people using your software.
I know it's difficult to gather feedback, but try to at least talk often to your product owner (or the equivalent person in your team). In our profession, few things are as sad as good software no one uses. Communicate with your users to prevent this from happening.
Oh I knew all these things already
Good for you. It took me several years to learn these lessons.
I know that any experienced developer will read this article and think, "All these things are obvious". It's true, they are, but only after you thought about them, or after you felt the pain of ignoring these ideas. In this series (Advice for new developers, or Things I wish I had known when I started programming) I'd like to continue sharing this type of ideas, I think they can be useful for a lot of people.
I hope reading this article was useful, and that you learned one or two new things.
What to do next:
- Share this article with friends and colleagues. Thank you for helping me reach people who might find this information useful.
- Read the next article in the series.
- You can find helpful books to continue investing in your carrer in the recommended reading list.
- Send me an email with questions, comments or suggestions (it's in the About Me page). Come on, don't be shy!