How to be a great developer? It’s not only about good code

By Diamantino Campos

Allow me the boldness of writing about being great in my work area. Am I fit to write about it? Well, I’ll write about how I try to be a great developer every day.

We all want to be better at what we do for a living, either for financial reasons, self-esteem, step up in our career, or any other valid reason.

A software engineer is no different, besides belonging to an industry constantly changing and evolving. The software engineering field has different particularities, such as:

• having many different approaches to solve a challenge;
• the right solution can quickly turn into a bad one when the context changes;
• and the fact that most of the time, our work is analyzed by non-experts that make decisions based on a perception of how everything fits. For example, a website or an app created by an entire team versus the unit of code created by the developer.

In this article, I’ll give my point of view and what approach I take to improve as a developer.

By the way, it’s easy. We don’t need to have the hand precision of a surgeon, nor the physical strength of a construction worker. We need to use our brains, for real.

I’ll assume you are a graduate or have learned the basics of programming.

I consider that a good developer must be able to perform at least half of these tasks:

• code (Captain Obvious is here!);
• understand the project he/she is integrated into;
• find solutions for problems;
• follow the teams and project goals;
• recognizes opportunities to improve him/herself, the team, and the company.

Don’t look only for money when choosing a company. The first interviews are hard, we don’t know what to ask, so we listen to the interviewer talk about the project, the company expectations and the wage they offer, and how it’s an excellent fit for our career.

Try to understand how the company and, more precisely, how the team works. Ask some questions like:

• Does your development process include code review? (we’ll get to this later)
• Do you work with up-to-date tools and software languages? And do those have traction?
• How is the project team organized?

The first projects you participate will influence the rest of your career. Believe me! Either by the methodology, software languages, or technologies, you’ll learn and eventually become an expert.

I chose my University internship and first contract based on money. I got lucky because, even though it was not a perfect company, it did have some good developers from whom I’ve learn a couple of things. By the way, it was Java and Adobe Flex 3 (it did have traction back then, not now thanks to Apple for killing Flash), and 12 years later, here I am (still) coding Java.

I’ve been to a lot of interviews where the recruiter just told me how well the company treated its employees and how good they earned. No details were given about the projects, responsibilities or expectations of my work.

One day I came out of an interview thinking: “If I accept, besides my salary, what do I know about what I will experience in this company?”. From then on, I forced myself not to leave any other interview without the answers to these questions:

• “How many people are on the team?”;
• “How is it structured?”;
• “What are the technologies and versions?”;
• “How close to the final delivery is the project/product?”

Working in a team, we have constant incentives to improve. The fundamental one is having at least one mentor willing to share. It can be your boss or colleague. Look at how he overcomes his challenges. Learn, study, and even copy from his work. If you’re in the early stages of your career and when you look around, you think you’re the best, you either need to be more modest or to look for a new challenge.

Another major bonus is the code review policy. Don’t look at code review as “your work being judged” by your teammates; look at it as the ultimate shortcut to improve your technical skills. You are getting free personal classes with real-world examples!

So, you found a quick fix for a bug? Have you thought about it 2, 3 times? “It’s just a new condition in a component, and it works,” you say. Be sure that your code does not affect some other functionalities, and that is compliant with the basics of programming. You don’t want to get too blasted in code review.

Remember, when I talked about my first job? There was no such thing as a code review! I did have a good team leader from who I’ve learned about technical aspects and communication, but he left the company just after one year. I had the feeling of being stale. Because of it, I decided to go to another company, where I thought I would learn more. Looking back, and as a bit of advice for you (how bold am I to write about being great and give you advices) do not rush because of a short period of no “new things to do” but do not wait too much when you are “not learning from anyone”.

If you are smart and dedicated enough and follow the previous tips, you will be a reliable developer, for the least.

A typical developer day has 8h of work, which is not 100% dedicated to our current tasks. Besides the regular pauses so your brain can breathe, if for some reason, you are not being assigned any task for a couple of hours, you have an excellent opportunity to learn something related to your work.

Be aware of the deep dark world of flying cats on the internet. They make 1h look like 5 minutes.

Do you know the basics of the project you’re working in?

• How your work integrates with the rest?
• Are you only fixing bugs? What are those bugs preventing the users from accomplishing?
• Are you building some REST API? How and for what will those be used for?
• Are you creating a new UI component? Where will it be used, and why does the project need it?

Remember that you only have a couple of hours at most, be as pragmatic as you can. Understand the direct surroundings of your work and not the entire project at once.

We want to excel. Let’s do this. If you are like most of us, you’ll have to go further and take some of your free time to learn more. You can rest if you want, and you’ll need it, but if you’re going to be a great developer, there is no magic pill, you’ll have to invest. Trust me: money is cheaper than time. Take some of your free time, and look for new approaches of coding, read examples, learn from accredited blogs, and optionally buy some books focused on the technology you are working in, or want to work.

Still about my journey… After I changed companies, I met a person who took Java certifications (I didn’t know such thing existed). That made me think that to be better, I’d have to invest more in myself. So, I started studying in my spare time. The first two books I read were “Spring in Action” and “EJB 3”. More than learning about these frameworks, I learn a lot about code structure and best practices.

I also recommend the great Clean Code from Robert C. Martin.

As a bonus tip: accept failure. Even if you developed something thoroughly, you’ll fail sometimes, and that’s ok as long as you learn from it. This is something called experience. Experience is not the sum-up of working years; the experience is the sum-up of faced situations and lessons learned.

Once, I was in a very ambitious project that was meant to optimize resource allocation from a private hospital, whether beds, nursery hours, surgery rooms, etc. This was a project with multiple interdependent teams. The input for my team was another team’s output and a third-team needed our data as input. All work was coordinated through “acceptance criteria” (AC) and a “checklist”. I got mine all set, except that the developer from the third team was not interpreting a very particular AC as I was. This had no impact on testing nor pre-production data, but one Sunday of August I received a call from my boss, and the client was not able to use the tool. The problem could have been avoided if I had a skype call of 30min to a final check with the other developer.

I hate to fail, but all my mistakes were great lessons. Either in a small task or in a project, be as meticulous as you can. Accept and learn from the outcome of it.

After some time evolving as a developer and becoming a team leader at Xpand IT, these are the core things that I value while becoming a great developer.

We know that not all human beings have the same capacity. Some learn faster, some think faster, some are very theoretical, and others very pragmatic. Accept your way of doing things, fix what you are doing wrong, and follow the path you want for your career.

Being a good professional is the primary key to be a great developer, just like for other jobs, except that ours have a dark world full of flying cats waiting to be freed.