Top 10 skills every software consultant should have:
2. Writing tests
3. Refactoring code
4. Understanding transactions
5. Understanding performance tuning
6. Understanding scaling
7. Knowing when NOT to be on the bleeding edge
8. Transparency with clients
9. Accepting of feedback on your code
10. Being polite
After more than two decades of professional software consulting experience, I have worked with many software engineers. The caliber of these professionals varies greatly. The best software engineers, who also exhibit excellence in consulting, have similar capabilities. These are my top ten skills every software consultant should have:
1. Listening – this is certainly the most important. The greatest software engineers I have worked with typically listen more than speak. They tend to listen carefully to details from clients on business rules or feature descriptions, or listen to other software engineers and formulate in their heads additional questions or potential solutions. I believe that many software engineers care more about getting their point across than listening and carefully dissecting the information. Listening is a skill. Mastering that skill will certainly make you a better software consultant.
2. Writing tests – all software engineers must learn how to write tests (and implement them). Many developers have a good understanding of determining different scenarios to try and break their own code and often test their code manually with those scenarios. The problem with just having a manual test is two-fold. First, generally these testing scenarios are not documented and often are determined on-the-fly. When it’s just in your head you will always forget something. Next time you look at the same code, you may come up with different scenarios. Secondly, having written tests that are automated ensures that your thought process lives on for future developers who might touch your code. Many developers I have met tend to have the same response when I mention writing automated unit tests. “There’s no time in the schedule for that.” I do understand that response, as often clients are pushing hard on the schedule and unit tests are the first thing to be eliminated. Being a good consultant means explaining the importance of unit testing for producing a quality product. I believe that most software consultants don’t push hard enough on this because they just don’t like writing unit tests. Write tests!
3. Refactoring code – as software engineers, we tend to code our initial thoughts and see if we can get that initial try working. Often we need to modify this code to get the software working as needed. Frequently, this initial working phase of software development can yield unclean code, such as bloated methods or non-optimal coding structures that are either not performant or not DRY (Do not Repeat Yourself – copy/paste code), or simply code that is difficult to understand and which requires comments. Refactoring your code ensures better code, better reuse, and easier-to-understand code. Without doing this you may have successfully completed your feature or solved your defect, but now your non-optimal spaghetti code becomes someone else’s problem and is potentially more prone to defects. Refactor often.
4. Understanding transactions – it seems nowadays many software engineers don’t understand the concept or think in terms of transactions. For so many decades transactional processing has been key to software engineering and today is no different. It’s true that lots of web development includes interactions with users that don’t require any form of a transaction, but many applications still do. Understanding a solid foundation in transactions is critical in thinking about how to solve business problems. Learn transaction processing and think!
6. Understanding scaling – great software consultants will ask questions such as the following before they write their first line of code for an application. “How many users will be using the system?” and “How many concurrent users will be using the system?” These questions and several others must be asked before starting a project in order to help determine the best architecture, stack, frameworks, networking topology, etc., to be used. Here’s a good article discussing various aspects (not all) of scaling.
8. Transparency with clients – this is another extremely important aspect to being a great software consultant. Generally, software engineers are introverts and do not like sharing. They would rather stay up all night trying to get a piece of functionality done rather than tell the client the real timeline. This is a dead-end. You must keep the client informed of both the good and bad aspects to your development project. Sometimes the client will ask you to implement a feature in two weeks. You, understanding what it truly takes, should explain the real timeline (let’s say four weeks) and be able to provide the details of why your estimate is most likely correct. Now with this, you need to put on your consultant hat and work with them. Maybe they can remove some functionality. Maybe they can prioritize the sub-features and you can build them in that order. Maybe you can provide them weekly (or daily) updates so that they have a better understanding of your progress. Maybe you can add another resource to help you. All of these are part of being a better consultant and being transparent with your clients.
9. Accepting of feedback on your code – I have learned so much from other developers whether they have 30 years of experience or one year of experience. Having someone review your code is a great way to get another perspective and increases the potential for refactoring. Some software engineers are not comfortable with others reviewing their code. I believe they are worried that they will be called out for “bad” code. Of course any developer sharing their code or reviewing code should be professional and be giving or accepting of polite suggestions. I have learned a great deal from others reviewing my code, whether it was better ways to implement the code, finding flaws in my code, ways to refactor, or performance improvements. The bottom line is that you can’t become a better software engineer in a vacuum. Continual learning from others is always necessary.
10. Being polite – this should go without saying, but being polite with others – whether that’s other developers or clients – is a must. People react better to those who are polite and not cocky. I have worked with several developers who, although being great at coding, were impolite and weren’t interested in listening to other developers or the client. This interaction causes friction and more importantly doesn’t lead to the best code or the best application. Bottom line: treat others with respect, you may learn something.
These are my top ten, but clearly some of these items are subjective and there are certainly more items on my list. At Solution Street these ten items have proven to define great software engineering consultants working here at the company. I tend to think of these important skills regularly when interviewing potential employees and in my personal growth. I hope you find them useful, too.