Engineer

Some background

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.

Responsibilities

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.

Basics

Engineering specifics

Be familiar with standard programming building blocks

• Standard data types such as string, int, float, array, hashmap / dictionary, linked lists
• Flow control mechanisms such as if and switch statements and for loops
• 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

Write idiomatic code

• 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

Debug issues

• 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

Advanced

Engineering specifics

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.

Techniques

Invest in yourself

Consume voraciously

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.

Business value

Understand the business goals or problem. Don't start without that knowledge

Before thinking about the technical design, understand the problem statement and expected business value. What are the client goals? Do they aim to increase market share or tap into a new market, make cost savings, or something else?

Use: Elevator pitch, product box

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.

Use: Epic estimation, options comparisons

Technical delivery

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.

Use: High level approach, high level design, low level design, non-functional requirements

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.

Use: Play through scenarios to uncover hidden costs, options comparisons

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".

Use: High level approach, high level design, define and document code/naming standards and patterns

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.

Use: Current, interim and target architecture, innovation budget, skills matrix

Relationships

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.

Use: Options comparisons, play devil's advocate to your own ideas, be balanced, don't rubbish ideas

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.

Use: Take emotion out of decision making, be inquisitive about motivations

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.

Use: Retrospectives, pairing

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.

Use: Operations epics and stories, with internal users such as support engineers as the persona

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.

Use: Role playing, chaos engineering

Quality

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.

Use: Definition of done, test strategy, code standards, stand-ups, end of sprint reviews, retros

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.

Use: Issue tracker and/or physical board up to date, branching policy, definition of done

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.

Team

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.

ISO

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.