The definition of a good professional varies from company to company. A good professional in a startup might not be considered capable in a big company and vice versa. Similarly, a freelancing professional might have contradictory skills to someone working in a product-based company. The top-performing engineers from different companies would be heralded as the best professionals by their peers but all of them are top performers for very different and quite often contrasting reasons.

Let’s consider the case of monitoring and observability. A person in a healthy and stable company would be super organized. They would have set monitors and alerts which most of the time tell them with pinpoint accuracy what is wrong and where even before any user complains about it. A big company has on-call rotations. Each person, for example, is on call every 6 weeks. That means they can enjoy 6 carefree weekends even if the live DB is rimraffed^.

Someone in a startup or a very young company might not have such monitors. Checks, pre-checks, and pre-pre-checks to raise alerts as soon as possible could be missing. For example, in an ideal world, a PR that can cause a performance issue should not be merged. There should be a rigorous test suite that benchmarks the performance of each PR with the main branch and doesn’t allow merging if it fails. If someday, after having read best engineering practices, you do that in a small company in an ideation phase and block some developer from merging his code, you might get a call from CEO to let that PR pass. CEO would have his own reasons. Maybe to fix an issue, which if not done could churn a customer who brings in 33.33% of the company’s total revenue.

A developer in a big company implements checks to minimize surprises while someone in a small company might cause surprises if they do so.

Having such contrasting viewpoints of how software engineers operate in various setups, makes it tricky to define what makes a good professional in software engineering. However, it’s quite trivial to identify a good professional when you work with one. Also, on the flip side, if you enter an office and ask who is the a**hole, almost everyone will point to the same person. If your company has none, you know you are in a good company.

I wouldn’t be too hung up on defining a good professional. The general definition of a professional is pretty straightforward and simple but I would build upon that.

Oxford dictionary puts it as

“the high standard that you expect from a person who is well trained in a particular job.”

Generally speaking and in our industry what I call a good professional is someone who is reliable and I can trust that they would get the job done with minimal surprises. Reducing the number of surprises is a core responsibility. Its implications are so big that you can consider it a rule of thumb to become a good professional.

Minimizing surprises works at many levels. As an entry-level engineer it might just be expected that you show up on time, do what you said you will do, ship the part of the software that is assigned to you, and keep stakeholders updated. We will talk about managing stakeholders in upcoming posts. With flexible schedules, showing up on time is usually reduced to meetings but being reliable is equally important. If you usually work from 9 to 5 and some people regularly engage with you during that time, it’s good to send in a message if you plan to change that schedule for a day or permanently.

As a senior-level engineer, you would be expected to ship the code and make sure it’s useful and see it through end to end in production. End-to-end includes taking care of analyzing requirements, writing code, testing code, putting in instrumentation to debug it later, putting in alarms where necessary, taking care of performance, and seeing it through production and beyond. Most people stop worrying about their code once it is in the main branch. Go beyond that and you will greatly increase your standing as an engineer.

At each point in the development cycle, you are expected to minimize surprises. Getting incomplete or flawed specs could be put on the product manager or your line manager but taking a step further and running a sanity pass of those specs will change the game for you. Your company will benefit as a direct side effect. Most people in small and medium-sized teams would appreciate it if a developer comes back and say that this “ABC” flow in this new feature could be done in “XYZ” way and that would be better in this and this way. Obviously, don’t do this for the sake of doing it. I see some people do this all the time and unnecessarily. But you must do it when it is necessary. If you do it correctly you will minimize surprises to the organization. You will also, in a low-key way, highlight the fact that your manager didn’t do his/her job well. These little things are going to make you a stronger, likeable, and a reliable professional.

Full-stack engineers in early-phase startups have the ability to ship a feature based on a one-liner problem statement sent over slack. On the other hand, a corporate developer would find it difficult to work through unless the specs are detailed and crystal clear. They would bother product managers for every tiny little spec. Managers will happily answer and that is expected as well. If someone from a small company bothers managers with every detail, that might get categorized as a lack of ownership.

You should have the ability to work according to the environment and expectations. A professional software engineer in a startup vs a corporate world can have very different skill sets. Unfortunately, we have a tendency to consider engineers from big companies to be better professionals but that is not true. It's a fallacy because usually companies grow from startup phase to corporate phase and we incorrectly correlate the company's growth with the growth of engineers. An engineer writing unit tests is considered good. A solo engineer writing unit tests during ideation is ridiculous and a waste. Not writing tests doesn’t make him any less professional. Not having the capability to write unit tests is bad. This is why I encourage people to have a variety of experiences. More on this in upcoming posts.

Updating stakeholders as simple as it sounds is sometimes not straightforward. Once I was working as a front-end developer on a project which was doomed to fail. It was a disaster for the client but interestingly my company, at least what I know, still considered it a success because they respected “SOW” and made money from it.

We were giving development services to external clients so we had little skin in the game and the metrics that define success are drastically different than the product companies. This reminds me of Steve Jobs trolling consultants. He asked an audience, "how many of you are in consulting". Quite a few raised their hands to which Jobs said in a derogatory tone, “Oh that’s bad! … you should do something”.

In that project, we were more than consultants though but anyways. We followed “scrum” in that project. Each day, in the stand-up I along with other engineers used to give updates. Our technical delivery manager, a very busy person, who was also engaged in at least 3-4 other projects also attended stand-ups quite a few times. In each stand-up, I used to tell what is not working and it will take more time than committed. It was a typical services company’s over-committing scenario for the given timeline. I highlighted it every single day and it was updated in JIRA. I was of the opinion that my status is well-heard and understood and that is all I needed to do. A couple of months later, we had a product demonstration with the client. It was a total disaster and the client escalated that the team is not good enough. The next day the delivery manager comes in the stand-up and asks "why on earth nobody alerted him about this". Yes, just like that. He asked about the very thing I was telling every single day in standups. Standups are useless anyways. It took me some time to absorb what happened. It made a lot more sense when I was managing 4 different projects.

What happened was that our delivery manager was usually occupied with multiple projects and most of those projects had firefighting going on at some level. Routine firefighting was so normal that it almost became white noise for senior management. This is more often the case with many services companies I have observed in the eastern part of the world. I do not have much experience with western development agencies, yet. To truly alert the managers, what I actually had to do was to go to stakeholders personally or send an email that whatever is going on is not going to end well. I was not thinking from the stakeholder’s perspective. I thought I was doing my job according to the JD. That was not enough.

You have to know what you are doing is actually making an impact.

When alerting, alert in a way it’s truly heard. Think from a busy person’s perspective and see how you need to highlight your concern. Alerting a peer of an upcoming disaster is very different than alerting a CEO.

Professionalism is a broad topic but if you have to extract one key point from here then that would be to minimize surprises for everyone who could be affected.

Play the game you are in. The game is very different in a startup vs a services agency vs a corporate company. Go above and beyond the call of duty to do that and it will pay dividends throughout your professional career.

One word of caution though, do remember that the skills that make you a good professional are not the skills that will make you good at business... or life.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.