It's also about being pragmatic, understand tradeoffs, discuss ideas and make the better decisions based on business needs. Questions like "Should I use a NoSQL database?" or "Should I run Kubernetes?" need to be made in based on the business strategy. Of course, you also need to consider how many users this application will need to support in the next 12 months. Evolutionary architecture is very different from ingenious design.
But how do you get this information? You have to do the boring part of the job talking with stakeholders and domain experts. This career is also about extracting value from conversations. We have an entire knowledge domain based on how to deal with business complexity called Domain-Driven Design, and one of its foundations is to make a common language with your domain experts.
Being adaptive is also essential. It's not about following the Scrum framework by the book and saying that you work with Agile. It's about adapting your work based on the most important thing. For example, how can you focus on developing the next feature if the rest of your team is working on a critical incident? Especially if you work in the Spotify model, where the squad should be responsible for maintaining their own software running in production.
Ten years ago, containers were something new, but now they are part of any developer's daily work as DevOps culture has become more common. As developers, we can use and understand infrastructure tooling to make our daily work easier.
Bug management is also an important part of the job. How can we better evaluate the impact of a bug instead of just relying on the dev team? Production bugs don't need a database intervention, but they do need a deep investigation to act on the root cause and avoid them from happening twice. The best way to avoid this is to focus on the beginning of the development process with good unit test scenarios that represent the business rules. If possible, have a great integration test suite covering meaningful scenarios. You don't need integration tests for everything.
A meaningful part of software development is explaining ideas via text or tech diagrams. It's not necessary to follow UML by the book, but you should follow some conventions. You will also need to write tech decisions with ADRs or RFCs, opening the discussion to a larger group.
What about coding skills? They are fundamental to how you make all of the other parts and make a delivery. They are essential, but with a broader view, your code will focus on the right thing.
Interest links
- https://martinfowler.com/bliki/DomainDrivenDesign.html
- https://kubernetes.io/
- https://www.docker.com/
- https://works.hashicorp.com/articles/rfc-template
- https://github.com/joelparkerhenderson/architecture-decision-record
- https://sre.google/workbook/incident-response/
- https://martinfowler.com/articles/is-quality-worth-cost.html
Top comments (0)