The one important thing I learned from "Beyond Developer" by Dan North

The one important thing I learned from "Beyond Developer" by Dan North

In this talk, Dan North speaks about ways of becoming someone more capable than just a person who writes code. He describes a set of virtues of a person who has both impact and influence.

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.

External motivation

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

Are you interested in data engineering?

Check out my other blog https://easydata.engineering

Internal motivation

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 ;)

How?

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.


Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you watch programming live streams, check out my YouTube channel.
You can also follow me on Twitter: @mikulskibartosz

If you want to hire me, send me a message on LinkedIn or Twitter.


Bartosz Mikulski
Bartosz Mikulski * data scientist / software/data engineer * conference speaker * organizer of School of A.I. meetups in Poznań * co-founder of Software Craftsmanship Poznan & Poznan Scala User Group