Software engineers are often seen as the victims of a wrong development process. Everyone wants something from them – product managers, designers, testers, customers and they want it now. But do we remember what a great fellow developer looks like?

Inspired by a comment from a close friend of mine when I shared Mike Cohn’s latest What I Want for an Agile Christmas, here’s the other point of view – what a manager would like the New Year’s resolutions of a software engineer in an agile team to be. Here’s a list of New Year’s Resolutions of a great software engineer.

I will understand the user story!

I will read the requirements (in whatever format they are) carefully. Two weeks of programming do not spare two hours of reading the documentation.

I will make an effort to understand the requirements and assist in creating the user stories. I will write meaningful implementation tasks.

I will contribute to the requirements and the design with my technical expertise, so we come up with the most valuable features for our customers.  I will share any technical risks as early as possible. I will propose the most optimal solutions.

If a task is not appropriately described, and I can’t start working towards it, I will not look away sitting on my hands and waiting. I will ask the author. If I weren’t able to reach them by any means, I would do quick research on my own, ask teammates, browse our knowledge management system, do whatever I could within a reasonable time to figure out what this is all about. Ideally, there should be minutes of meeting or another piece of written information about any clarification. If there isn’t any, I will propose we do MoM in the future.

Still, if I can’t proceed, I will take the next task in order of agreed priority. I will not just start refactoring or fixing random bugs or gold-plating for other features. If there’s nothing I could take next indeed, I’ll help a fellow developer, do some pairing, write tests, use my idle time to improve my relevant skills.

I will always ask until I get a clear answer, why we are doing this feature, and how our customers and our business will benefit from it so that I can be the most effective while implementing it.

I will not undermine the customer’s requests. Very often they don’t know what they want, but sometimes they do. I will study the business domain, talk to product people and customer success team so I can better understand the world of our end users.

I will confirm I have enough information before I give an estimate. I will be very explicit what it includes – is this the time for writing the code or it also includes time for research, writing tests and fixing bugs, even issues with deployment.

I will manage my time efficiently. I will raise flags as early as possible about underestimated tasks, overlooked risks and dependencies and will not wait for the end of my initial estimate to announce those.

I will not respond with it can’t be done; it’s too difficult, or it’s not worth the effort; it’s too much work without completely understanding why the feature is required and without doing proper research on the implementation.

I will not mock the mock-ups. I will not blame or make fun of the designs. I don’t enjoy my peers having fun over my code during code reviews, and no one else does.

I will not delete code without notifying anyone just because I don’t want to dig into it.

I will not make assumptions but always validate my decisions with the product manager, fellow developer or test engineer.

I will write good code!

I will write high-quality code on time. I will follow the best practices of software engineering. I will continuously learn new and better programming manners, technologies and approaches that could optimise our processes.

I will check and re-check and ask a colleague to check my work before I even send it for testing. I will never deploy a change before it’s tested.

I will share and write down any technical risks and product impact that my changes have so that the rest of the team, the product and especially the test engineers can take adequate decisions and cover them.

If I finish early, I will not stand still.

I will never make significant, moreover risky changes and… go on vacation. I will also not go on vacation right after the release.

I will never do copy-paste! If I have to, I’ll make sure I do it correctly.

I will always try to write as many and adequate tests as possible. I will work closely with the test engineers, so we cover the most critical and high-risk scenarios.

I will not close bugs by design without telling the author or without questioning the design and without suggesting better solutions even for future implementation.

I will not close or return bugs with cannot reproduce without making sure I read the bug description, even if it’s long and there are many steps, I understand the bug, and without really trying to reproduce the bug.

I will expect proper, meaningful, yet compact and easy to reproduce, literate, detailed bug descriptions and additional artefacts like videos and screenshots. And I will appreciate the effort.

I will not get offended and irritated when a bug is found in my code. I will thank my teammates, who test it. I will not be bored when I fix bugs or write tests. I will finally get it that tests and bugs reported to me make me a better programmer and save my and the company’s reputation.

I will not use the design and the requirements as an excuse for a poorly implemented feature and missing functionalities. I will always try to look from various sides and challenge the requirements and the design constructively.

I will not update the versions of external packages and dependencies without telling anyone. I will not start severe refactoring without an actual reason for it, like upcoming modification of the feature due to high priority business requests.

I will take notes and assure traceability where necessary. I will make use of existing tools and practices for increasing my productivity. If they don’t suffice, I will propose better ones and work towards continuous improvement of the process.

I will respect and help my teammates!

I will not cope with inefficient processes and heavy procedures unless the business is mission-critical and indeed requires them. Still, I will continuously suggest improvements to our workflows to reduce bugs, waste and rework.

I will care for the team well-being. I will not contribute to low morale and neglect burnout teammates. I will raise my concerns and try to help in establishing more efficient workflows. I will encourage teamwork, sharing knowledge, working towards clear common goals and… beers after work. 

I will not let finger-pointing and blaming culture slide. I will not ignore it when managers or team leaders regularly expose team members’ mistakes publicly and set “fear of fights” mood. I will not tolerate teammates talking behind each others’ backs.

I will not accept working overtime as the norm. I will demand clear priorities and goals, clarified requirements and commitment from management as early as possible. I will say no to unreasonable requests.

I will not resist process changes only because it’s something new and I’m not used to. I will be open-minded and look forward to learning new things.

I will be on time for meetings. I will participate actively but not annoyingly. I will not argue only for the sake of argument. I will listen and provide relevant feedback, bring bright ideas and support my colleagues when they have good ones. I will never mansplain.

I will try to communicate clearly and concisely, respect my teammates time and be always open for questions.

I will do my part of the engagement equation. I will try to understand, follow and share the company culture and values. I will be a conscious and (reasonably) hard-working, positive, knowledgable and resourceful colleague that everyone would love to work with.

I will not leave in a year, because I came only to raise my salary and to add the company and the technology stack to my résumé.

Being a software engineer is not easy, it’s one of the hottest professions. Being a really good one, it’s rarely about the technical skills only. It’s a complicated environment and understanding how software development is made is crucial, and for sure, it’s not only about writing the code.

Continuous improvement is not only for processes, but it’s also for people. The more transparent we are, the easier the communication and, of course, with a bit of an effort from all sides, the fewer hectic moments we will experience at work. Any best practice is better than no practice. “It’s not my job” is not the right attitude, it doesn’t create working software. At the end of the day (year), we’re one team with one goal. The greatest professionals are great people first.