A static archive of Markus Tacker's tweets. Follow me on Mastodon: @[email protected].
Stop becoming a full stack developer - your efforts are futile.
(Follow me now for the prototype of a talk I am working on. I would really love
to hear your thoughts and especially your input on the point I am making. But
for now: let's start with an observation.)
This is the predominant way of seeing a developers career. You can apply this
also to other specializations but let's look at the skill measure of a
full-stack developer (FSD), not only because I used to call myself one ¹.
The skill level is rated from Junior to Principal, you start as a Junior and
work towards being a senior. After that (some make Senior in three years) it
gets a little fuzzy what happens. But generally you reach a level where you have
more responsibilities and teach others.
This is of course a very simplified view, since being a FSD means you need to be
proficient in a multitude of areas. Your skill is not a single value but differs
across these professions. However they all are required to call yourself a FSD.
Ask yourself this: what is your overall level? Your highest skill (I observe
that many call themselves FSD if they can tell what the abbreviation MEAN stack
means), your lowest skill (you could never be truly a FSD), or an average?
I guess you see that the label "full stack developer" is problematic already.
Because if we look more deeply what is needed to develop applications we also
need to take into account the various requirements of different sectors. Here
the requirements will be vastly different.
Footnote on this: the great practical FSD roadmap by
@MadhavBahlMD:
https://codeburst.io/a-practical-approach-to-web-development-1ee37a4ad829
Your skill is always relative to the sector you are working in. If you mostly
work on eCommerce you will have deep knowledge in performance, payment systems,
user journeys. If you work on internal banking systems your fields of expertise
will have an entirely different focus.
All of the above also needs to be viewed through an important 4th dimension:
time!
Your skill is a function of the time you spend improving it, and since you
cannot simultaneously improve all skills at the same time, your total FSD skill
will fluctuate over the years.
Software is an incredibly fast changing field and especially the skills many
associated with a FSD have a half-life of a few years. A fraction of your total
working life!
This all means you will never truly be a "principal full stack developer" or any
other kind of authority as a developer. Sorry.
(Queuing the main point here, btw)
You will always lack important skills to realize the best work you have ever
done. It's impossible to achieve greatness solely on your own.
You will always depend on other to work with you and the more experienced you
are the more other depend on you enabling them to achieve their best.
Now the problem we as a profession have is that we do not teach this! There are
tons of tutorials, courses, lectures in universities on the technical part of
our work. People will happily attend conferences on framework X, database Y.
Meetups exist for every language.
But we do not educate ourselves in collaboration. But collaboration is the only
way we can make up for our own limitations.
Collaboration between humans however comes with a cost, communication is messy,
cultures are different.
I always say that I'd love to have more software problems, because they are easy
to fix. But people problems is what I have to deal with.
And in the past I invested very few time in educating myself on collaboration
and communication. I want us to change this.
Here are some techniques and frameworks (yeah, don't we love us some nice
frameworks) I hope we can look into and adopt them, or even extend on them like
we do for developing software.
Because as with software frameworks, communication frameworks should prevent us
from doing the same mistakes over and over again and have best practices at hand
which will let us achieve our goals faster.
The premise of this talk is to give the listener then an overview over these
frameworks, and this is where I now need your input. Does this resonate with
you? Would you be interested in hearing this talk?
I will keep on collecting more and turn this into the second part of this talk.
One things I am practicing for a while is Non-violent communication:
https://en.wikipedia.org/wiki/Nonviolent_Communication
It works very well for me in that it gives me a process to dissect communication
and try to find the true message, which might be wrapped in emotions and hard to
get initially.
But this is (at least how I practice it) a passive method, where I do the
analysis and do not go in an exchange with the other person about the way they
communicate. Maybe a little subtle when I mirror their request back to create a
better shared understanding.
Typically here, I did not have a formal training in it but discovered it on my
own a few years ago. So it would be interesting to learn if there are developers
out there hat received training, and how that went for them.
I also know about The 5 Love Languages (5LL,
https://en.wikipedia.org/wiki/The_Five_Love_Languages), which were introduced
to my by my friend @rinkkasatiainen.
Since most people work for some kind of affirmation 5LL gives a good model about
the different ways humans are receptive for gratification and it is important as
a collaborator to understand what drives them and how I can give them the
feeling that I value their work.
The four-ears-model is a valuable complement to the earlier mentioned
Non-violent communication, since it also models a message as a composite of
various aspects, and it helps to identify and separates the different aspects
the were amalgamated by the sender of a message.
https://en.wikipedia.org/wiki/Four-sides_model
For me it's helpful to identify these aspects in order to better understand the
true meaning of a message.
A few years ago I took the time to read The Core Protocols
(https://liveingreatness.com/core-protocols/) but for me they are (like
Holacracy, https://www.holacracy.org/) are very regimented approach to human
interaction which works for some, but in my experience requires a lot of
discipline.
In my experience as an organizational coach these systems do not work well with
heterogeneous teams where you gradually change something, it's hard to explain
to an "outsider" why this makes sense and it can actually feel inhuman.
It is however fascination source material to look into because it highlights
very explicitly communication issues and how to deal with them.
@pcalcado recently published an article about
communication which is puts a spotlight on the aspect of discussion and decision
making (one common source for conflict and often a time where power dynamics
become painfully visible):
http://philcalcado.com/2018/11/19/a_structured_rfc_process.html
I guess the second part needs more GIFs. Nevertheless, I think it could be a
valuable contribution to a conference to look into more of these ideas about
collaboration and communication and make them available in a collection.
What do you think?
One point I want to stress on the talk is this:
We developers happily pay (money, time) for getting up to speed on tech topics.
We don't do this for communicatio/collaboration skills.
And this is not because companies don't offer this. They rarely offer structured
tech training either.
Adding another method I find useful:
@ldavidmarquet's ladder of leadership is a
really powerful concept which describes "angles of freedom" in a collaborative
relationship. What's great with it is that it's a gradual system and makes the
implicit explicit. https://youtu.be/-sri5wyth4I
Here are some resources that seem worth checking out:
https://compassionatecoding.com/ by
@aprilwensel The course about 20 emotional
skills: https://www.theschooloflife.com/business/ Emotions: a Philosophical
Introduction https://www.coursera.org/learn/emotions
... and I definitely have to start listening to
@SoftSkillsEng: the weekly advice podcast
for developers.
Adding it here as a great training option:
https://twitter.com/skillsmatter/status/1127483575971000320?s=19
It looks like this book will be a good read for this topic:
https://www.goodreads.com/book/show/541132.Punished_by_Rewards?ac=1&from_search=true
How you expect your knowledge as a developer to grow vs. how it really is:
