The one important thing I learned from "Beyond Developer" by Dan North
For me, the crucial part begins when he starts talking about building a product. In his opinion, programmers should understand the business context because it gives them a sense of meaning. I couldn’t agree more.
Yet, I think that I have a different reason for such a belief. I believe that Dan North was talking more about the prerequisites to being an influencer in the context of the product. I focused on the part of his talk which helps a software engineer to be motivated.
For sure, knowledge about the domain is essential. If you see the impact you have on the daily life of the users, you will be heavily motivated.
The motivation keeps people interested in the product they build and makes them take their job seriously. Motivated teams want to cooperate with stakeholders and even go the extra mile to contribute to the requirements.
To see the full impact of your work, you must adopt Dan North’s vision of the stakeholder. According to Dan,
“Stakeholders are people whose lives you touch.”
From my observation, programmers who need challenges to be motivated, get their motivation from one of the two things: they either love working on diverse problems or try various solutions. I am the first kind of person.
Seriously, I am a “to-do list person.” I have a handwritten to-do list on my desk with little squares drawn next to every item, so I can “check them off” when they are done. Check them off and move to another thing. This is the thing that motivates me the most.
I would rather solve new, exciting problems using old tools, than re-do the same thing over and over again using a new, fancy technique.
The one thing
Fortunately, Dan has a piece of advice for people like me. If you want to move to another problem, you must make yourself available again. Sounds like a simple idea. How do you do it?
First of all, you must make yourself redundant. Sounds scary. I was promised a new exciting challenge, so how do I become redundant?
You must share your knowledge. You can write documentation or do pair programming with someone. You can even draw a poster and hang it on a wall if nothing else works ;)
Maybe your company organizes internal conferences, and you can give a presentation about the problems you solved. Is there a community of practice? What about attending one of their meetings?
Even better, do both. Give a talk and write everything down, so new employees and other people who could not attend the meeting can use it too.
The wrong tool
The mean of communication does not matter unless you are thinking of using Slack. Let me tell you my opinion about Slack.
Slack is not for knowledge sharing. Slack is the place where knowledge goes to die.
Do whatever you want. Create a Confluence document, a GitHub page, write a blog post on an internal blog, whatever. Just don’t keep valuable information scattered around in a chaotic way across multiple Slack channels.
Did you enjoy reading this article?
Would you like to learn more about software craft in data engineering and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- Data/MLOps engineer by day
- DevRel/copywriter by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz