Skills of a Successful Software Engineer - Building non-coding skills, keeping up to date.

[James Elsey]

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

[Fernando Doglio]

Hey James, great question!

And one that is definitely not easily answered! Keeping up-to-date is never trivial, especially if you can't do it during your working hours.

While it is true that you can't really read the docs on how to do better requirement gathering, for example, one way I've found useful to both, check if I'm doing right and learn new techniques at the same time, is to openly write about it.

Showing how you work to others who might be going through the same process as you can help you get some great feedback. People might ask questions that can spark different PoVs or even show you that you're actually doing things incorrectly.
This is the equivalent of getting a mentor, if you can't get one, you can at least, "consult" with other like-minded individuals.

Other than that, make sure you get feedback from your management often, that way you can also get a confirmation of whether or not your current approach is valid, and if it's not, adjust accordingly before it's too late.  

I hope I was able to help, sorry I couldn't give you a more direct answer,  but I don't think there is one TBH.

Let me know if you have further questions!

James Elsey wrote: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