The most important trait of a senior engineer
I thought it was technical knowledeg and communication skills.
Of course they are important. But at a senior level, I find myself in a mentorship and team building role quite a bit. And here I have to constantly work on an important skill.. Empathy.
Empathy is the ability to feel and identify with another person. While designing a product, I am constantly debating how it impacts a junior developer. How do I simplify it? How do I address the pain points. In this article, I’ll try to go through some of these considerations while picking the underlying tech stack.
Learning curve
Learning a new skill is hard. Especially in UI engineering, the number of frameworks that come and go are insane. I myself struggled with the transitions from jQuery to YUI to Ext.js to Angular.js to React. When designing a project, I now first look at the learning curve. I was delighted at how nice angular.js was. But I was horrified when Angular was released. React was fun but having to switch between class based and functional components was icky. Then came React hooks. This made component development so simple. You now do not have to explain class based development. At least for brand new projects.
Your daily productivity declines if you have to constantly refer to documentation and code recipes on stack overflow. jQuery, good old angular,js and React fundamentals are easy to memorize. Frameworks such as Ext.js, Angular + TypeScript, RxJS etc, not so much. I am not blessed with a great memory and I struggle constantly trying to remember minute details.
How do you know if a framework is complex? There are a few signs:
It comes with a cli.
A cli encapsulates all the complexity in the framework. Ember and Angular are prime examples. Just because a cli builds an immediately runnable scaffold doesn’t mean anything. There is that hidden complexity that someday you will need to master. If you ever have to eject in create-react-app, good luck understanding 290MB worth of complexity. Fortunately, create-react-app is the only CLI I recommend in React. If you ever have to eject don’t even consider using it.
An extensive config file.
Just because it is a JSON file doesn’t make it easy. At this point I am just putting up with Webpack because I have to. It is one of the most confusing, hard to learn bundlers.
The size of documentation.
I’ll pick on Webpack again. Who has the time to read and master all that? What is the guarantee that Webpack will be relevant five years from now? Remember the fate of Bower, Grunt and Gulp. Rollup and Parcel are gaining momentum now.
Redux’s has a big learning curve. I’d still recommend going through it to understand how Redux works. But using the library is not straightforward. It is tough to reason how mapStateToProps, mapDispatchToProps and connect() works. I believe that now all you need are the reducer and context hooks to do state management. (UPADTE: Redux now supports hooks. No more boilerplate code).
Complexity
Systems grow in complexity over time. If not kept under check, you will find your product developing into a ‘legacy’ system that is now so complex that you are planning a full rewrite in three or four years. Thus, keeping it simple is not just an axiom. It has to be the underlying mantra when you design your system. Complex functions must be abstracted away, interfaces cleanly defined, production and test code must be refactored as they evolve. Dependent packages must be upgraded at decent intervals. Strong linting and nit-picky code reviews must be in place.
Cognitive load
Whether it is the framework, library, bundler, build pipeline, it helps to not tack on additional complexities than required. TypeScript is very popular now. But the language adds its own syntax noise. The more code you write, the more constructs you tack on to your language, the more difficult it becomes to reason/understand it. In fact the less code you write. the less bugs you will have.
Typing your code requires extra effort in design and debug. We’ve just managed to eek out best practices (good and bad parts) in JavaScript.
But typing has value in communicating function and data interfaces such as React Proptypes. My approach is to use only where typing adds value. Typing for typing sake is insane. It is a waste of effort and creates more crap to maintain.
Teach best practices not new frameworks
Given a choice, I will pick TDD over static type checking any time. TDD is a very effective methodology to help develop software low in bugs. Developers can enhance and refactor existing code base with confidence.
Learn how to write clean code. Books and blogs by Robert Martin is a good place to start. Familiarize yourself with code smells. Evolve your style with industry best practices. Know when you can make exceptions. For example, even though the Redux reducers with switch statement violate open closed principle, I still use it just like that. It is much cleaner and familiar
Learn functional programming style. Understand how a declarative style differs from imperative. Seen code like this?
let newList = [];
oldList.forEach((item) => {
if (item.value > 0) {
newList.push(item.name);
}
})Just using forEach() instead of a for loop isn’t functional enough. The code is still imperative. Instead you can write:
newList = oldList.filter(item => (item.value > 0)).map(item => item.name);Why is it better? You write less code and it is very simple to reason about. Functional patterns such as map, filter, reduce and compose are time tested.
Be very careful tacking on npm packages.
Even with tree shaking, adding new packages will start adding to your bundle size. New developers have a tendency to use cut and paste code from stack overflow without understanding it. They also tend to solve problems by importing new packages. Before you add that nifty function ask yourself:
- Can this simple function be written in-house?
- How much bloat will this add to my build?
- What are its dependencies?
- Who is the developer? Is it just one person or a group of individuals? Does it have any backers? Will it be maintained long term? Will this be a bottle neck for you to upgrade other packages or language features. What if there was bug in the library?
- What is the security risk? Can this package at some point be hijacked and malicious code inserted into it?
- How big is the feature set? Are there things in it that you DON’T want devs using? How will you stop developers from using them? Can you justify the restrictions? For example, after you adopt Typescript in your React code base, can you stop your team from using “Classes”?
Knowledge gaps
Whether it is a new hire or an experienced person, there is bound to be a few knowledge gaps. The worst thing to do is to throw some documentation at and dictate to the team members to just adopt. Junior engineers have a tendency to learn just enough to get by and then depend on google and stack overflow. Not a good way to go.
For UI, there are several affordable online resources available such as frontend Masters and egghead.io. Sometimes, you need to recommend a path to learning. Always get them trained on the basics. Allocate a couple of hours every week to address issues or do small workshops.
Knowledge on the internet is free to those seek it. One of the biggest challenge you will face as a senior developer is to get strong developers to think differently. Sometimes, it takes many iterations of recommendations, code reviews and guidance to get everyone onboard. Sometimes, you will realize that you had been wrong all along because you didn’t think in their shoes.
