Dimi Tech

Leveling up: Becoming an Expert

25 Aug 2022

This article outlines what it takes to become a Professional Software Developer - an Expert in every sense! If you’re an aspiring programmer and you’re ready to level up not only your coding, but also your productivity, problem-solving, and life in general, read on!

If you’re a beginner, read Part 1 - Advice for Beginners first.

This writing is divided into three equally important sections (and summary):

MINDSET

Are you enthusiastic about software?

If you’re not genuinely enthusiastic and infinitely curious about computing, you should probably consider a different profession.

We all have our own reasons for entering this field, but if your primary motivation is money, for example, you will never become great - it’s low quality fuel.

On the other hand, even if you start out full of enthusiasm, that fire can fade after some years in this business. I became disenchanted by the software industry very early in my career, because the state of modern software is, frankly speaking, horrible. Human greed, laziness, short-sightedness, carelessness ruin software and extinguish enthusiasm.

My advice: seek out excellent teams and meaningful projects.

Always look for other ways to rekindle your love for programming:

  1. Build personal projects that bring you fulfillment.
  2. Read high-quality, inspiring books.
  3. Keep a connection to what initially drew you to software - for me it was understanding and rebelling against the systems of control, hacking, video games, simulations, audio…

When we step back and look at the bigger picture, it’s hard not to marvel at how humanity has built incredible applications just by pushing electrons around!

Ideology

Understand that software exists because of people, and (I believe) it should serve the people.

As a technical worker, you’re part of a larger society, and your work affects it (to a certain extent).

So think about how your work affects the bigger picture - and whether you care. But whatever you choose, at least do it with some agency, not just passive acceptance.

If you care about your freedom, start here:

In software, it’s extremely rare that something is really “new”. That doesn’t stop companies from marketing their products, frameworks, libraries, APIs etc. as “revolutionary” and “game-changing”!

Don’t fall prey to this. Focus on fundamentals and principles that almost never change (for example, SQL has been in use since the 70s”). Otherwise you risk investing a lot of time in something that might not stay around for long.

Don’t mindlessly let others (especially giant corporations) dictate how you use and build technology.

Develop critical thinking! (if you’re not sure how - start by learning about cognitive biases and marketing…)

And yes, even question what I write in this article.

HARD SKILLS

Become highly proficient in your main programming language

Another “common sense” point that is not so common in the real world, it’s actually rare!

Learn at least 90% of your programming language features, tools, the runtime (how it executes), the ecosystem and the philosophy. Read lots of books in order to find those which are the most valuable. If your language has source code available - study it, get to know it really well. If it doesn’t - then why are you using it !?

Keep up to date with latest updates, news, books, conferences, podcasts, blogs, best practices…

Simply put - be an expert in your language!

Be familiar with different programming languages & ecosystems

There’s a high chance that immersing yourself in a single programming language ecosystem can’t give you enough wisdom and perspective about programming. Different programming language “communities” have different areas of focus and, to become well-rounded, you must expose yourself to many of them.

One example: (Today, in 2022) JavaScript programmers don’t know much about software architecture, design patterns & best practices in general because the ecosystem isn’t oriented around that. Contrary to that, Java programmers have focused on design & best practices for over 20 years, but they are not exposed to the beauty and writing efficiency of dynamically & weakly typed programming languages for example. Ruby programmers have put extreme emphasis on software testing and more efficient ways to write code (for example using Vim or Emacs). Functional programming paradigm and languages have their own valuable perspectives to offer.

Of course, over the years, different ecosystems become influenced by each other and features and paradigms get adopted across the languages. But I think it’s best to learn each paradigm in a language where it’s dominant - start with an OOP language, then a functional one, then a systems language… massive knowledge is obtained by doing so.

Learn low level programming

Take some time to learn C, Data-Structures, Algorithms etc…

Low level programming might not seem relevant at your current job, but not knowing it will certainly hurt you at some point. You can introduce memory leaks & inefficiencies no matter how abstract your programming environment is, so it’s good to develop an instinctual understanding of these things.

There’s also an inner sense of peace & fulfillment that comes from finally understanding how computer programming really works.

Books I recommend:

Become an expert in software testing

Time and time again, I’m shocked by how little developers know about testing their code. For me, tests are critical in order to have a bigger codebase that is successful.

Developers are reluctant to learn testing because it’s boring to them or what not, but we’re here to achieve a goal of bringing value to our users, not to have fun and mess around. If testing is not enjoyable to you I’m sorry, but you must learn it really well, there’s no way around it.

I personally enjoy writing tests, especially because it protects my codebase from regressions as the codebase grows over the years, and that removes almost all anxiety that I might have about my software.

Testing will force you to write better quality code, because the code usually has to be designed in a decoupled manner in order for it to even be testable.

Testing is a huge topic and I don’t want to go too deep into it - but for any software professional it is an essential skill.

You have to know UNIX based systems really well (GNU/Linux, BSD, MacOS…)

Most of the world’s software runs on UNIX based operating systems, so knowing them is simply a must.

Not knowing the UNIX philosophy and architecture, how to best work with terminal emulators and so on, means that you probably don’t really know how computers work.

Graphical Operating Systems like Windows do very well in protecting the users from the intricacies of the underlying operating system and its mechanisms. This is not where we want to be as programming professionals, we need to know how things REALLY work.

Aside from that, majestic projects such as GNU/Linux help humanity instead of hindering it. GNU/Linux based operating systems are mostly free of charge, with source code completely available to anyone.

This means that even the poorest & unluckiest of us have some sort of a chance to learn computing without paying huge corporations for a licence (or resorting to piracy). Also we can learn from the actual source code, which is not the case with proprietary operating systems. GNU/Linux systems (usually) respect the users freedom, because you can actually see the source code that (when compiled) you’re running on your computer - it’s completely transparent. Proprietary operating systems (usually) exploit the users instead - invading their privacy, limiting their computing freedoms, wasting time, showing ads etc (this is unfortunately becoming a trend in the GNU/Linux world as well…).

Also this is a HUGE topic, but the essence is - know your damn UNIX!

Infrastructure & Operations

This ties to the previous point, because in order to understand computer infrastructure - you must know GNU/Linux because most infrastructure is based on it.

Most servers run GNU/Linux or BSD because it’s the most efficient, powerful and reliable system for the job.

Infrastructure plays a huge role in today’s world, where most software is composed of different infrastructure pieces (services) that work together in concert.

Having a strong knowledge of servers, services and cloud infrastructure is a must for any software professional.

With the rise of DevOps, every professional developer needs to know how to work with infrastructure really well. You need to be very familiar with at least a single cloud provider and need to know & keep up to date with recent developments and best practices. As a developer, you can’t know every single service that a cloud provider has to offer, but you need to know the basics at the very least.

You can also get certified by a specific cloud provider, but that doesn’t guarantee deep knowledge or expertise.

You also need to be a student of DevOps and think how you can deliver software in a most efficient way, in the shortest amount of time possible.

Another huge topic, but simply put: Infrastructure & Operations knowledge is a must!

Software Architecture & Leadership

It’s relatively easy to write software that works. But writing software that keeps working over years and decades, as it grows and evolves with teams of programmers developing it, is orders of magnitude harder!

This is where Software Architecture becomes critical - it’s what separates professionals from the rest.

For larger, long-running projects, the software can’t just “work”, it must possess other (non-functional) qualities such as: maintainability, extensibility, scalability, reliability, security, performance, and more…

But that’s just one aspect. Software Architects must also know how to: structure teams, define component boundaries, establish collaboration processes, and make decisions that scale the project while keeping it reasonably malleable.

Being able to perform architectural assessments is another indispensable skill, since many companies are in the business of helping other companies deliver software (through outsourcing, offshoring, near-shoring…).

To be an effective Architect, you must also understand and have influence over people. Supported by technical excellence, you need to convey certainty and authority to help close deals, and gain buy-in from engineering teams.

Leadership & Software Architecture represent the highest levels of technical and interpersonal skill. This is where I invest most my energy and time, allowing me to deliver immense value to software companies.

These topics are huge, often abstract and hard to learn, but still essential to any software professional. Here are some books I recommend on this topic:

Conclusion: You must know everything!

No one can become and remain an expert in all aspects of software development at once, but you must have at least a very good understanding of all of it.

Focus on a couple of main fields which you will dominate, and be at least very good at the others.

If software development were an RTS game, there should be no “shroud” - you must be aware of the entire map. While there will always be “fog of war”, meaning you can’t control every part of the map at all times, you can maintain control over your main areas and stay well-informed about the rest.

Starcraft Mini Map

You must be able to juggle with different technical areas: focus on one while neglecting the other, then move to the next one etc…

It’s the same way with life: sometimes you need to put your entire focus on business and neglect your health, then you tone down the amount of work on the business and start training harder & eating healthier but then you maybe neglect friends… etc. etc.

PROFESSIONALISM

Act like a professional!

Technical skills still being in high demand can make tech workers feel overly privileged and relaxed, to the detriment of productivity. Many businesses suffer because of this. Me, I want to be a professional and create massive value. If you want this as well - read on.

Show up on time and be prepared. Start and end your work day on time, do not work on weekends or overtime, avoid burnout. Arrive at meetings at least 1 min before the start time. Come prepared, don’t ramble - just get to the point. Give the most information in the least amount of words possible. Be fast, learn how to speak effectively.

Be aware of who is in the “room” (virtual or physical). Don’t spew technical details if there’s someone there who can’t understand it. Keep the conversation relevant to the people that are in the room.

Be accountable - when you say you’ll do something, make sure that you get it done. Keep a physical notebook around with a checklist of TODO items, for me that’s the easiest way to remember what I need to deliver.

Never promise or commit to something what you can’t deliver. Don’t let people influence you into making unreal commitments.

Learn to work with your tech team. You must face the external world as a unified entity. If one member of the team fails - everyone fails. Nobody cares if one of your team members screwed up and that’s the reason you couldn’t deliver - you all failed. If some of your team members are not pulling their weight - let them go. There’s no need for the rest of the team to pull other peoples weight and earn their salaries - it just creates resentment & inefficiency. It’s best to cut this out immediately - you can’t be afraid to hurt people’s feelings.

Remember - the goal is (hopefully) to bring value to Humanity through the product that you’re creating. Everything else is a distraction.

If it’s in your interest to slack off and be sloppy - please change industries. Better spend your time doing something that you really want to do. You’re definitely not going to work in my teams :)

There’s A LOT to write on this topic and these are just the basics, but let’s move on.

Focus on business

Most of us programmers don’t make a living building web applications, mobile applications, desktop applications, embedded applications… we earn our money by building BUSINESS APPLICATIONS! (read that again if you need to)

This kind of software exists within the context of a business, so it must serve the business. Almost all effort should be focused on delivering value to paying customers, whether individuals or organizations.

Eric Evans explains this in the “big blue book” (Domain Driven Design) - read it. Software must model the relevant business processes in the most effective way. Achieving this requires strong communication between “business” and “tech” people. Since software serves the business, technical professionals often need to understand business people more than the other way around. Avoid technical jargon when speaking with C-Level executives, managers, or non-technical customers - it’s rarely necessary, and gets in the way of alignment. So both you and your code must speak the language of business.

On the other end, there are the end Users, who are usually the reason software generates revenue. Cultivate deep empathy for them. In any user-facing software, UX is king - never forget it.

Also, be aware that your (and other workers’) time and effort is funded by the business. Utilize it the best you can in order to produce outcomes, not just outputs. You can produce as much output as you want (endless lines of code, features etc…), but if it doesn’t lead to real business value (positive outcomes), you’re not only useless, but harmful to the company!

Outcomes > Outputs

Start by reading these books:

Agile Software Methodologies

There are many ways to organize software delivery, but most projects benefit from some form of Agile methodology: SCRUM, Extreme Programming, Kanban, or others.

The Software Development LifeCycle (SDLC) is an extremely important, practical intersection of software and business, and any programmer must be well versed in it.

From experience, I would advise to not be dogmatic. Keep the processes lightweight, and adjust them to the team’s needs (well that’s the whole point of being “Agile”).

While some programmers might see it as a waste of time, practicing true “Agility” is essential to delivering value quickly and effectively!

Start by reading:

  1. The Agile Manifesto
  2. The SCRUM Guide
  3. Extreme Programming Explained (Kent Beck, Cynthia Andres)

Solve difficult problems!

Be willing to do what others are not!

Be a problem solver: volunteer to solve the toughest and most frustrating problems that everyone else avoids. This will make you an indispensable member of any team, and you will become highly appreciated. Difficult features, tricky bugs, errors, persistent warnings… be the first to jump in and tackle them. If nothing - you will learn a lot about the system and programming in general.

Another thing - remember that no job is “beneath” you. Regardless of your “seniority”, always be willing to solve “mundane” problems when no one else is available to handle them.

Building software is challenging for many reasons. One of them is that building a feature takes a certain amount of effort, but polishing it and handling all the edge-cases often takes just as much effort and time, if not more. It’s the ninety-ninety “joke” rule:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

— Tom Cargill, Bell Labs

Be the one who always pushes the “other” 90% to completion!

Legacy projects

Don’t shy away from “Legacy” projects. A legacy project likely has paying users, which usually means it provides some kind of value to people.

This ties in to my previous point of solving difficult problems - legacy projects are often some of the most challenging codebases out there!

Legacy code is not necessarily bad code, it simply means that it has been around for a long time. In reality, since most programmers are not professionals, the code usually is bad, and dealing with bad code is a valuable skill worth investing in.

We’ve already discussed how software serves the business, but sometimes the business itself is broken beyond repair - which can make the code seemingly impossible to fix. Unless you have wider influence in the company, focus on what you can control and do the best job you can there. Create an “oasis of professionalism and seriousness” within your software team(s) and set a shining example to the rest of the company.

If the business continues to make poor decisions and fail despite your efforts, it’s time to say goodbye and move on.

In addition to standard “best-practice” software books, read this:

Collaboration

When working in a team, it’s easy to become myopic - ignoring others’ work and losing sight of the bigger picture.

It’s very important to keep an overview of the entire project and know the critical parts well, even if you didn’t produce them yourself. Take responsibility for the whole project, and encourage your team to do the same. Understand that the team must deliver results, regardless of individual performance.

With this mindset, code reviews make much more sense and become far more valuable. When you treat your colleagues’ code as your own, and vice versa, everyone shares accountability for the project’s success.

This way of thinking builds the proper relationship with both the codebase and the people, making it easy to transition into leadership positions.

English proficiency

Even if it seems trivial, speaking and writing clear English makes a big difference. People understand you better, and clients and stakeholders respect you more.

Strong communication builds trust and effective leadership, because everyone can rely on you to convey ideas accurately and concisely.

Having a rich vocabulary also enables you to write more expressive code, making it easier for others to read and understand.

I recommend picking an accent (American, British…) and sounding like a native speaker in both speaking and writing.

SUMMARY

Even though this article might feel intimidating, it’s far from an exhaustive list. These are simply the areas I consider most important at this point in time… There’s always more to learn, so the best time to start is right now.