How to Not Suck as a Software Developer

The following are not enforceable developer rules. I did not climb a mountain and receive the following laws from a higher power. And they are not industry shattering new ideas or techniques. Rather they are common sense guidelines we are all guilty of breaking once or twice (hopefully not too much more) throughout our professional careers. They were born from informal peer discussions on how we can each improve individually (and as a part of a team). And most importantly - not suck.

alt text

Most of the time software is complex, has a lot of moving pieces, and involves code with far reaching tentacles. We are imperfect people creating imperfect software decided by imperfect people with changing imperfect requirements. No one expects perfection. However, when developers choose to ignore the following, they will most likely get bit. And worse, it makes the entire development team look bad.

1. The feature is more important than your code.

Reasonably discuss the feature with the business owner (or customer). Listen to them. Communicate your ideas effectively. I know that last sentence sounds like a cheesy resume bullet point, but show or walk through the feature (or bug) with the business owner. Interact and value their time.

Get your technical reviewer (or senior developer) involved early. Do not over architect. Yet, do not oversimplify. Determine the balance and trade-offs. Accept peer input. Your code sucks. My code sucks. A second set of eyes is always good. Get over yourself.

2. Literally test your feature.

If this means using a mobile device, then use one. Usually, it doesn’t really matter how long testing takes. Ideally testing time should be built into estimates. Unsure how much testing is involved? Ask your technical reviewer (or senior developer) for additional test scenarios after you have shown him yours, but remember that you own the testing.

Do not assume. Ask the business (or customer) what they are expecting to “go live” with. Use tools or automate tasks to save time. Reach out to QA (Quality Assurance), but remember they are not your personal minions. You perform your own thorough testing. Value their time. Enjoy the satisfaction when QA is unable to find an issue.

3. Be a boy scout.

Leave the code in better condition than when you arrived. If you see an easy code improvement, and you can support and test it: fix it. Don’t be wimp about it. If you cannot address it, at least acknowledge it by entering a detailed change request. Assign it to yourself. Make sure your manager sees it and ask to work it into the schedule. Passing the buck is lame. (See aforementioned point about overdoing it).

4. Have a healthy obsession.

Think about security. Think about performance. Think about edge cases. Think about partners. Think about IT and their roles (support, deployment, monitoring, etc.). Think about usability for customers (or users). Communicate with your Business Analyst or SME (Subject Matter Expert).

Continually discuss timeline impacts (i.e., additional testing) with Project Management and loop in your manager. Tell them you are slipping sooner, rather than later. Again, it’s a balancing act among quality, time, and scope. Your manager (ex-coder turned manager) years removed from day to day coding may not know the latest wiz-bang programming language syntax feature or the latest Javascript library, but he knows software, business processes, and inter-department collaboration.

Bounce coding ideas off your co-workers and manager. Self-educate yourself – read books, listen to podcasts, take advantage of PluralSight (or Safari Books online). Share knowledge with others. Help improve your company’s code and process so that you can get things done.

5. Admit mistakes.

Own them. We all make them. Point the blame thrower at yourself.