Software Engineering Values that Everyone Should Practice

Photo by Markus Spiske on Unsplash

Although we are living in a non-ideal world, that’s doesn’t mean we shouldn’t even bother to strive for the best of our capabilities to create an ideal world. The same thing with software engineering, there are some values that we should practice to improve ourselves and others. The thing is it’s not all about the code, it’s so much more than that. Remember that every value let the team make progress in delivering value.

Engineering

• Adhere to current standards and best practices in deploying and running services in a distributed environment, and writing high quality, clean and operationally ready code. Writes modular code that is easy to test and maintain. Code that is easy to test and maintain has fewer bugs, fewer bugs make the maintainer happier, happier maintainer create fewer bugs.
• Understand the importance of testing, and writes unit testing consistently. Writing unit tests helps a lot, because the shorter the feedback loop, the more early we found the bug the less effort we need to spend to fix it. Nonetheless, it doesn’t mean you shouldn’t do any kind of user acceptance test or integration test. Ensuring that all units work together as expected is more important than ensuring each unit works as expected independently. Writes integration tests, with both real and fake calls to dependencies as needed.
• Understands and participates in company workflow practices willingly and on time, including but not limited to daily standup, sprint planning, retrospectives.
• Ensuring that pre-production and production pipelines are working most of the time. Ensuring that test pipelines for services or apps are kept green. Test your changes locally, ensure you’re not deploying unwanted changes and becoming the bottleneck for others to deploy their changes.
• Commits code continuously to master/main branch allowing releases to production to happen incrementally. Instead of creating one big bang change, it’s better to do a bunch of smaller ones. Smaller changes are easier to be reviewed, and tested. It also means code conflict can be solved early instead of waiting for a long time for the big bang code is being merged.
• Create technical documents for their products and services. Good documentation takes time to be created. But it’s a worthwhile investment that delivers several values, such as knowledge can be spread in the team more easily, newer people can be introduced to the system easier, discussion regarding new features and bugs can happen more productive because each stakeholder can understand the service better.
• Documents and evangelizes best practices and standard operating procedures (SOPs). In a big team, knowledge disparity is quite common, one team struggle should be shared with others to speed up solving the same problem.
• Understands and applies cybersecurity best practices while building products and services, as well as in their processes and operations.
• Actively seeks knowledge and applies it to the systems. Continuously identifies opportunities to improve code and design of team’s products and services, as well as team’s SOPs and practices.
• Builds monitoring dashboards, and alerts, to track service and stack level performance.
• Responds and addresses production issues, in a timely fashion. Owns postmortem process for production issues. That includes identifying root causes, coming up with and implementing corrective measures, and communicating findings with the team and stakeholders.
• Works on tasks in accordance with the priority. It’s all about delivering maximum value as fast as possible.
• Exercises good judgement when implementing requirements, and avoids introducing technical debt. However, when must, selects technical debt that is relatively easy to address shortly after launch, e.g. debt that has limited impact on customers and business.
• Learns from your and others mistakes. Everybody makes mistakes, the difference is based on how they respond to the mistake.
• Accept feedback without being defensive.
• Adaptable to new ideas and input when it makes sense.
• Thoughtful and detailed code reviews; asks the right questions, pushes back on bad code, push back on code with no tests, etc.
• Give directions to other engineers on best practices. Mentors other engineers, and acts as a source of guidance and technical leadership. Mentoring and pair programs with other engineers.

Product Ownership

• Own the product. You are responsible for your products in every aspect. You need to know your products metric, technical and business side. Learn the business side of your product.
• Understand the impact of their work on the customers and the business.
• Takes initiates in taking on tasks and/or solving bugs, even when unassigned.
• Builds products iteratively. Able to identify and release an MVP to market, successfully building on top of it afterwards.
• Estimates possibilities, complexities, and impact on both business and technical of each deliverable.
• Understands business requirements and goals, and tailors design and implementation accordingly.

Communication

• Be an effective, and collaborative team player. Remember everyone comes from different backgrounds, we should complement each other instead of fighting each other.
• Communicates ideas effectively in both verbal or written form. Uses email effectively, not just chat. Captures precise and insightful meeting minutes and notes, and action items, effectively. Speak your thoughts clearly. Understand that the way you communicate your ideas matters.
• Speaks up when faced with blockers or impediments, e.g. reach out to reviewers instead of waiting for feedback on code reviews. In a huge team with multiple functions and divisions, there will always be blockers. If you happen to see one, escalate it. It takes minutes or even seconds to escalate, yet it will save you and your team hours or even days.
• Doesn’t assume when requirements aren’t clear, and asks for clarifications instead. Clear requirements are paramount, sadly not every task has clear requirements. Remember clarification reduces the number of revisions.
• Comes up with well-thought arguments while presenting solutions. Uses data and metrics to back up their arguments.