4

It Is OK to Require Your Team-mates to Have Particular Domain/Technical Knowledg...

 2 years ago
source link: https://blog.jakubholy.net/2016/03/06/it-is-ok-to-requie-your-team-mates-to-have-particular-domaintechnical-knowledge/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

It Is OK to Require Your Team-mates to Have Particular Domain/Technical Knowledge

March 6, 2016

Should we write stupid code that is easy to understand for newcomers? It seems as a good thing to do. But it is the wrong thing to optimise for because it is a rare case. Most of the time you will be working with people experienced in the code base. And if there is a new member, you should not just throw her into the water and expect her to learn and understand everything on her own. It is better to optimise for the common case, i.e. people that are up to speed. It is thus OK to expect and require that the developers have certain domain and technical knowledge. And spend resources to ensure that is the case with new members. Simply put, you should not dumb down your code to match the common knowledge but elevate new team mates to the baseline that you defined for your product (based on your domain, the expected level of experience and dedication etc.).

For example in my team, we use extensively lo-dash, a library for data transformation (map, filter, etc.). We expect all new members to become comfortable with it before being productive. That means learning not just filter(cars, c => c.color === "yellow") but also the short-hand forms such as filter(cars, {color: "yellow"}), filter(cars, "family") (having a truthy property family), and even filter(cars, color? {color} : null) (you need to know that null == (()=>true)).

Of course I don't want to suggest that you should bring in all possible libraries and concepts and require all to know everything. I speak about a few but crucial, carefully selected libraries (and concepts). You also don't need to use everything a library (or a language) has to offer - especially if it offers too much. Talk with your team-mates and select what is suitable for you - the less the better :-).

The same thing applies to domain concepts - it is OK to expect and rely upon certain level of domain expertise, knowledge of business rules etc. (But you must make sure that all will have an opportunity to learn them.)

To help with on-boarding, you should write down what this expected domain and technical knowledge is.

PS: This idea was originally put forward in a much better way by Rich Hickey in has famous talk Simple Made Easy. (And I have certainly modified the message in quite few ways.)

Tags: opinion

Are you benefitting from my writing? Consider buying me a coffee or supporting my work via GitHub Sponsors. Thank you! You can also book me for a mentoring / pair-programming session via Codementor or (cheaper) email.

Allow me to write to you!

Let's get in touch! I will occasionally send you a short email with a few links to interesting stuff I found and with summaries of my new blog posts. Max 1-2 emails per month. I read and answer to all replies.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK