Hi Fernando Doglio,
I've been an engineer for over 12 years now, with the past few years leaning into a more lead role, and I'm finding books like yours to be increasingly valuable (although I have not read yours yet).
When I first started, it was all about the low level coding, all I wanted to do was write code, learn new frameworks etc, I didn't care about much else. Even during meetings I was always into the detail. Whilst I'm still "on the tools", I'm definitely looking through a different lens these days. As a lead, I am often tasked with more than just straight up developing, such as:
- Designing / architecting new solutions
- Wearing the analyst hat and digging into requirements to find out what the business really
needs rather than
wants.
- Writing user stories, being a few sprints ahead making sure the other engineers have work available.
- Reviewing PRs
- Pairing with other engineers to help them through difficult / new areas
- Interviewing
- Planning roadmaps with leadership teams, scoping new work etc.
My question to you, is how do you develop these new skills to make you a better engineer? How do you find new ways to make yourself more efficient at your job? I think these are difficult skills to develop, as you can't just google the latest documentation.
What "ways of working" are top engineers at places like Google, Atlassian etc doing?
I've found that working with other smart people and taking mentors to be the best way. Some things I have learned from working closely with other leads, that I have found useful:
- Stop being so rigid with unit testing; test the contract and be oblivious to internals, this way the implementations can freely change and not break all testing.
- Github etiquette, ensure commit messages
follow a standard. Do small cohesive changes, don't flood reviewers with 400 file changes.
- Follow guidelines on pull requests,
this one is for Go
- Log outcomes, rather than intent. Don't log "about to do x", but rather "did x" with some context of what happened.
- Follow the 12factor apps guidelines
- Documentation should sit as close to the code as possible, not on some crusty webpage that never gets updated.
- Always ensure requirements are clearly documented somewhere, and have assumptions if needed.
As someone who's been around a bit, interested to hear your advice on how you are keeping up to date with these softer skills.
Thanks