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.)
(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 ¹.
¹ coderbyheart.com/the-full-stack…
¹ coderbyheart.com/the-full-stack…
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.
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.
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.
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.
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.
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.
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.
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?
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: en.wikipedia.org/wiki/Nonviolen…
One things I am practicing for a while is Non-violent communication: en.wikipedia.org/wiki/Nonviolen…
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, en.wikipedia.org/wiki/The_Five_…), 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.
en.wikipedia.org/wiki/Four-side…
For me it's helpful to identify these aspects in order to better understand the true meaning of a message.
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 (liveingreatness.com/core-protocols/) but for me they are (like Holacracy, 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): philcalcado.com/2018/11/19/a_s…
---
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?
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.
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.
Here are some resources that seem worth checking out:
compassionatecoding.com by @aprilwensel
The course about 20 emotional skills: theschooloflife.com/business/
Emotions: a Philosophical Introduction coursera.org/learn/emotions
compassionatecoding.com by @aprilwensel
The course about 20 emotional skills: theschooloflife.com/business/
Emotions: a Philosophical Introduction 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:
It looks like this book will be a good read for this topic: goodreads.com/book/show/5411…
How you expect your knowledge as a developer to grow
vs.
how it really is:
vs.
how it really is:
