Desirable Traits in a Software Engineer

Hi all, this post is semi-informational, semi-conversational. I don't want to sound like I know everything because I don't. And I believe different people will have different views on this same topic, What I want to share is what I think are the qualities that will make a software engineer successful in his/her career. It is ok for you to agree or disagree with anything I write here, but I hope that none of this material is offensive in anyway to anyone.

Here are the desirable traits of a Software Engineer (working in any programming language) in no particular order of importance:

1. Understand the entire lifecycle of the job scope

A Software Engineer has already become an all-encompassing term to describe someone who knows how to make computers work in a certain expected behavior. This would essentially mean that writing code has become only a small fraction of a typical software engineer's day-to-day job. In my experience, I have spent much more time on doing non-software related stuff than anything else. Things like managing the company's red-tape processes (e.g. getting permission to a server, reseting password etc.), clarifying the work requirements, doing production support, and so on. The list is long and non-exhaustive. In short, software engineers are expected to know everything (strangely enough), and be able to get anything to work. So the key (trick) here is for you to know how many percent of your time and energy should be allocated to which task categories. There is no one right answer, but the exact allocations depends on your boss (and your boss' boss and sub-bosses ...) and it does not depend on your job description. The different tasks you will need to manage will all tie-in closely together and you have to try to streamline them to work towards your advantage (i.e. to make you look good to your boss, and NOT to produce the best software possible).

2. Manage your boss' expectations

Let's just face this. You don't need much or any technical skills in order to be a Project Manager, whom most of the time is the direct superior of one or more Software Engineers. Hence I'm not sure I find this funny but I'm not sure the managers actually know what we are doing and what it takes to do those things. Thus it is very important to educate your bosses and managers that you are not a superhero, you don't have all the life in the world to pull late-nighters every day, and nothing comes for free in this world. I'm not saying that all or most bosses don't know what to expect. I am just saying that if your boss doesn't really know what you need to do to jump through all the hurdles to get the job done, you have no choice but to educate them. No one likes having bosses with unrealistically high expectations that no one can fulfill.

3. Decide on a fine balance between software usability and top-quality

No one has all the time in the world to keep on tweaking and tweaking the code that he or she has written. You have to call the cut somewhere, saying, "I know my code does this and this, but I know it sucks, but I should not spend any more time on it." If your boss thinks that you are a superhero who can produce top-quality code (with complete test cases) without giving you enough time to do it, then you have to go back to point 2 above.

4. Be able to articulate well on your code and the software in general

It doesn't matter if you have written the absolutely best code in the whole world if you do not know how to describe it to others in such a way that people will say "Wow!". If you are not a UI (User-Interface) developer, chances are that most of your work is not visible to anyone (except the OS). Even if you are an UI developer, the factors that distinguish between a sloppy piece of software versus a top-quality piece of software lies in most of the invisible things. Hence, if you are a really good programmer, but yet you cannot sell your own product to your boss, then your boss (who never looks at the source code by-the-way) will not be able to assess your work in a proper way. Maybe they can start to appreciate you after time (few months easy), but in my experience, I found that it is not easy to get a proper manager who is able to appreciate the work for its true worth.

5. Know your business and technical domains inside-out

This point should be quite obvious I think. If you are able to answer any question anyone might have regarding either the business domain and the technical domain of your application, then you will be seen as an expert in your field (which naturally makes sense here). Don't rush yourself into stuffing everything into your head in a short time. You just need to be consistent to pace yourself and keep on learning as much as you can (no matter how much you think you already know). It is just like studying for an exam. It might not be a good idea to cram everything in one shot.

6. Understand what is the meaning of a "bullet-proof" piece of code

I have seen a fair bit of code in my work experience, and whether you like it or not, most of the code that I saw are not "bullet-proof". This is my own terminology. What does "bullet-proof" mean? It means that no matter what kind of input and execution environment you give to it, your code will NEVER FAIL. Let's just take a simple example. You might have some kind of workflow engine to process incoming requests. In ordinary states, we expect around 1 request per second. So the question to ask yourself is, "What happens if you get 100 requests per second?" If you have done your multi-threading right, then surely nothing should break. But the key here is to guarantee that the code will NEVER BREAK no matter what you throw at it. In my programming experience in both server-side and UI development, I have found that bullet-proof software doesn't necessarily require more code to be written, but they do require much more time and effort to put together, which is again another invisible aspect of the software.

7. Neatness

I'm not sure who will disagree with me on this point. The measure of the quality of a software engineer usually lies in the neatness of the engineer. It is almost a paradox to say that a programmer is untidy, but can produce great-quality software. By-the-way, I have never seen such a thing in my career. The neatness (whether inside the computer or outside the computer) of an engineer has a strong correlation with the quality of the engineer and his or her work. I don't have too many examples to speak of, but the Apple iPhone is probably the best example to illustrate this point. iPhone is not only neatly and aesthetically arranged on the outside, but it is the same in the inside (the things which you will never see). (By the way I am not an Apple fan.) Sloppy code runs sloppy, and sloppy people write sloppy code. This is just so fitting and easy to understand. Hence if you want to aspire to be a great software engineer, you might want to also get a clean haircut, neat clothes and so on, which will help you in giving you the right mindset to work with.

8. Don't waste time

This is one of those timeless truisms that apply to anything and everything that you will ever do. Try to imagine a 2-D graph with the vertical axis as "Amount of Work Done", and the horizontal axis as "Time". I think it should be quite obvious to you that if you don't keep on trying to push the vertical axis upwards (i.e. getting more work done), your graph will remain flat over time. In the end, one of the measurements would be how high you have pushed up the graph along the vertical axis at the end of the day, week, month, or year.

Hopefully this article is of some help to someone out there. The list above is not exhaustive and I'm sure you or I can add many points to it, but this is just to give a few practical tips on how to be a desirable software engineer. Thank you for reading and wish you a good career ahead!

My brief background: Computer Science graduate with few years server-side multi-threaded Java experience, and few months C# server-side and UI experience.