Engineer is a core role at Infinity Works. More of our people identify primarily as engineers than with any other specialism. It is also one of the broadest and most diverse roles, so pinning it down to specifics can be challenging.
Engineering is a broad discipline
Front end, back end, platform, mobile, data, full stack? There are many different labels which get attached to different flavours of engineering. We value all of these and deep understanding of the technologies we use is essential. But it's important to be flexible and able to pick up technologies and languages that you haven't used before. Seniority and progression are more a factor of increasing your breadth of experience and expertise than ever-increasing depth in one area.
This role can be carried out by those at career level CL11 Associate and above.
[Paint Drip People. Image from Kent Beck]
It's a long road with many forks
There is no one path toward becoming a more senior engineer, but in general variety of experience helps more than each individual problem you tackle. The accumulation of wisdom you get from this variety lets you gather more learnings to apply in new situations — experiences like working with different technologies, in different business domains, with different shapes and sizes of team and in different cultures all help.
It takes time to gain mastery with new technologies or parts of the tech stack. Sustained effort is needed and it can feel like a challenging journey at times.
[Dunning-Kruger Effect. Image from Daily Star (Bangladesh)]
It's not all about tech
Strong technical skills in a range of areas is important; as an engineer you should be able to get properly stuck into coding, testing, debugging and refactoring. As you gain experience you will identify principles and develop the opinions which form your distinctive style.
But you will also gain the wisdom to know when to avoid writing code, and how to become an active partner in defining and refining business requirements. This includes learning the basics of fields such as business analysis and user experience.
The detail of how you perform your role as an engineer will depend on the specific tech stack, the team structure and many other factors. The points below aim to describe the responsibilities in a way which doesn't get bogged down in these variations, while still being a useful guide.
Be familiar with standard programming building blocks
- Standard data types such as
dictionary, linked lists
- Flow control mechanisms such as
- The concepts of variables and scoping
- Method / function definition and calling
- The concepts of classes and objects
Be comfortable with code
"Code" can be anything from PHP to a bash script to SQL to "infrastructure as code" such as Terraform
- Can read code and follow the flow of execution
- Readily understand the data ownership and modification model from reading code
- Spot obvious bugs
- Identify obvious performance or security issues
Write clear code
Engineers spend much more time reading code the writing it. Code which is easy to read saves much more time than optimising for speed to write code.
- Write code which is as simple as possible to solve the problem effectively
- Follow the style and approach already established in the codebase or team, unless you agree as a team to adopt something different and have a plan to migrate to that
- Concentrate on code readability and comprehensibility over speed or ease to write the code
- Avoid large amounts of duplication, as this can lead to unmaintainable code, but use some duplication judiciously when this aids comprehensibility
- Different languages and frameworks have their own character and the communities tend to settle on a consensus of 'idiomatic' ways of doing things. Writing idiomatic code makes it easier for others to understand and maintain the code.
- Understand and use those idioms in the tech stack you're using
- Bend the rules when appropriate
Structure the solution to be maintainable
- Use well considered file and code structure and naming to make it easy to navigate and understand
- Use standard design patterns to aid separation of concerns such as MVC, facade, dependency injection
- Favour simple, explicit solutions over clever or implicit ones
- Prefer using libraries or well established patterns over inventing your own solution, unless there is a strong justification for doing so
Be results focused
- Start by understanding the business requirement / user need
- Stay focused on solving that and don't get lost in over-polishing of the solution
- Be imaginative and consider a range of ways to interpret or solve the problem
Design and implement data representation to support business model
- Incorporate data validation and normalisation in the design
- Choose appropriate relationships (1:1, 1:many, many:1, many:many) and know how to represent them in code and in databases
- Normalise or denormalise to tune for maintainability and performance
Test the code as part of implementation
- Structure code so it is easy to test
- Write unit and integration tests as a natural part of implementation
Test the system as part of implementation
- Structure external interfaces such as APIs and UIs to make them easy to test
- Write 'system tests' of these external interfaces as a natural part of implementation
Analyse small / simple tasks
- Contribute to the writing of user stories and acceptance criteria
- Consider functional and non-functional requirements
- Break stories down into tasks
- Estimate complexity and effort
Be a constructive pairing partner and peer reviewer
- Develop a sense of what 'good' looks like and use a clear set of personal quality measures when collaborating on work
- Take joint responsibility for the quality of the work rather than being a passive partner
- Consider the team consensus over personal style preferences, but challenge that consensus in a positive and constructive way when appropriate
- Give feedback in a constructive way (see Google respectful reviews)
- Handle challenging situations which arise in a thoughtful and considered way, generating shared learning rather than conflict
- Keep a clear head and a sense of proportion
- Use a methodical approach to track down issues
- Consider options and evidence without jumping to conclusions
- Use a clear mental map of how the system is put together to guide exploration and to avoid getting lost
- Keep a level head and don't act rashly, but also stay focused and don't procrastinate
Continue to get better at the basics
Many of the skills which experienced engineers excel at are the same things which beginners need to have a basic grasp of. Keep working at developing these skills as they are the foundation of becoming more effective.
Analyse large / complex tasks
- Lead the writing of user stories, epics and acceptance criteria
- Consider functional and non-functional requirements
- Break epics down into stories
- Estimate complexity and effort
Be familiar with multiple languages and tech stacks
- Compare and contrast between languages and tech stacks you are familiar with
- Use things you learn in one stack to enrich how you work in another without straying too far from the standard idiomatic ways things are done in that stack
Work across multiple layers of the stacks
Become familiar with multiple layers of the stack and able to work comfortably in each, using practices appropriate to each.
Gain broader skills
Deepen your understanding of other practices which contribute to effective technical delivery such as testing and the 'tester mindset', business analysis, scrum mastery, commercials. All will increase the value you can add as an engineer.
Invest in yourself
Read books, blogs and articles. Watch webinars, listen to podcasts. There is a huge breadth and depth and it takes continual investment to keep up to date. But don't let yourself be swamped. There will always be more to learn than you can possibly have time for, so prioritise and focus on what gives you most value.
Learn from others
Pay attention to how other people do things and learn from them. Adopt things you think work well, adapting them and making them your own. But also learn what to avoid from things you don't think work.
Understand the business goals or problem. Don't start without that knowledge
Keep the design grounded in business value
(Respectfully and politely) challenge designs which prioritise perceived architectural purity over business value or aim to meet functional or non-functional requirements which are in excess of what is needed, especially scalability or extensibility.
Focus on non-functionals
Have a broad understanding of the key areas which need to be considered when designing systems, paying particular attention to non-functional requirements such as integrity, security, performance, capacity, scalability, resilience, availability, recoverability and maintainability.
Keep it simple
Design systems which are as simple as possible to help with maintainability, operability and integrity. Consider alternative designs to remove complexity when it creeps in. Be mindful of the operational overhead of systems with many moving parts, interactions and dependencies.
Aim for harmony
The parts of a system should fit together and follow a standard approach unless there is good reason to deviate. Favour the "least astonishing solution".
The "right" technical design depends on the client's context [Advanced]
Be aware of the client context. Take the client skills and background into account. Consider and communicate ways to incrementally work toward what you think is the ideal solution rather than assuming you will be able to jump straight there.
Justify your thinking
Present ideas to the client as intentions rather than decisions which are a done deal. Justify decisions based on the effect they will have on the team's ability to deliver the desired outcomes. Where decisions may be controversial, present alternatives and explain why you favour your chosen option. Be aware of the client's context and background: decisions which seem obvious to you may still need to be justified to the client.
Cooperate with everyone
Work toward achieving a positive outcome, even if the client's thinking or processes seem cumbersome or old-fashioned. Sometimes we can influence these, but this needs to be handled carefully and it is usually best to avoid appearing to challenge them head on. Try to understand what experience or fear is motivating their thinking and look for alternative ways to make them comfortable rather than discounting their thinking out of hand.
Know when you need help and ask for it
Know when to ask for help. Don't give up as soon as you hit the first hurdle, but also don't slog away fruitlessly for hours.
Change your mind when it is demonstrated that you're wrong
Don't stick with decisions if experience gained through delivery shows them to be wrong. Important indicators that designs and decisions may need to be changed are often only clearly visible by experiencing the impact of these decisions during implementation.
Focus on operations
Have an operational model
From the outset, think of what you are building as a system preparing for production. Get used to working as you will once it is live. Build the tools which will be needed in production and get used to using them before go live.
Be ready for incidents [Advanced]
Establish and rehearse the procedures which will help you respond to incidents. The team may need to be on call. Lead by example and be part of the on-call rota.
Establish a culture of quality
Quality delivery comes from setting clear expectations and establishing a team culture where individuals hold themselves and each other to account. Take an active role in defining appropriate quality standards and processes. Lead by example, diligently following the processes you've agreed to.
Cover the basics
Focus on the basics like issue tracking, source control, pairing, peer review and CI/CD. Invest time in defining the test strategy. Ensure appropriate documentation is produced as part of delivery and tools and processes are in place to make onboarding easy.
Avoid perfection, don't nitpick
Don't seek perfection. Give your fellow team members space and when the solution they produce is good enough don't criticise minor details unnecessarily.
Build the team culture, keep people motivated
Be part of building a good team atmosphere where individuals feel empowered and engaged. Be approachable and always make time for colleagues.
Team output beats individual output
Don't be a hero. Focus on team delivery over your individual contribution. Prioritise helping others deliver their tickets over delivering yours if theirs are more urgent or important.
Give constructive feedback, seek constructive feedback.
Give regular constructive feedback to team members, and seek feedback from them. Coach colleagues when appropriate, but if you feel there is a performance issue then have a talk with your tech or account lead.
You'll carry out your role in accordance with the requirements of ISO9001 and ISO27001 as reflected in the Company's policies and procedures and the ISO9001 and ISO27001 organisational structure charts.