A Mature Developer

By Ankit · 2016-04-17 · Programming/Code, Quick Tricks, Tutorial/Links

Let’s call a developer reaching that 10x definition like achieving nirvana. He has experienced almost everything in SDLC, he is productive, quick to self-brainstorm, communicates what is needed, never let the shit spread, gels well with the team, create examples for others to follow, etc. Apart from technical competency what are the other qualities that a 10x engineer should have? Let’s find some answers and define these as bases for a mature developer!

Ownership

Get involved with what you are building rather than thinking 9-6pm and go home.
Once shipped, get excited about how your feature is doing. Are customers adopting? Are there any exceptions in production that went unnoticed when testing while in development?
Admit openly about the cases where things are going to break. Because of release commitments, sometimes we ship half-baked solutions. This is fine as long as the known issues are shared and agreed upon. But someone needs to highlight and drive consensus. Just don’t hide, they are going to eventually come and haunt you.
Understand about the work-life-balance and never compromise one for another. There are highs and lows in everyone’s life.

Tools, Tools, & Tools

Programmer are typists first[1]. If an automobile engineer doesn’t know how to use a wrench or screwdriver, you cannot grant him an excuse and let go. There’s just no excuse for it. You have to be good at typing rather than struggling with the keyboard & fingers.
Master at your favorite IDE. Today, most of the popular IDEs can facilitate many programming languages. Go explore your IDE, learn shortcuts and master it. This is the best thing going to help your productivity.
You cannot review a JSON object in a plain text editor, so stop arguing that it is okay to do it once in a while. Get yourself a specialized text editor: Notepad++ / Sublime. Whichever you choose, go to the plugins page and have a bunch of few installed to take your productivity to next level.
I use tools for everything. From Postman, EpochConverter, JSON Formatter, Schedule planner, HTML2Jade, Awesome Screenshot, building a lengthy web form with bootstrap, Grammarly, DNS/SPF probing, etc. There are smart enthusiasts out there who have built a right tool for specific work. Just, go, explore, you shall find few handy online-tools to bookmark.
Have a workable knowledge of Regular Expressions (RegEx). Think about a developer who struggled to write a Java program getting cleaned a text file and another developer got it done in just 5 mins trying a good RegEx with Find/Replace in any specialized editor. Time Saver!
Organize your Inbox: Too many emails in a day eats up all the time. Know the difference - what should be read and what should be not. Use Filtering Rules and Labels/Categories in your mailbox.
On top of labels, I use color-coding with them. Here is my thumb rule:
=> Green: anything marked green is important. Must read, without a miss. E.g. your team’s emails/discussions, emails from your manager addressed to you, production alerts when something goes down, MoM, etc.
=> Blue: anything marked blue should be read, either today/tomorrow.
=> Red: No need to spend time today. Read these once/twice a week as they need less attention. Throwing these to trash should not cause you information loss.
You have to figure out what makes you productive and adopt it in your daily life
My list is endless: (a) Have a git aware terminal to know which branch you are in, (b) SQLite Browser to quick load heavy CSV files and querying/charting, (c) Chrome extensions like Clearly, Force.com Logins, Grammarly, Tampermonkey …

Master at least two languages

Studies suggest multilingual exposure boosts children’s social skills[2]. That same rule applies to programming languages. Knowing two programming languages helps a developer open his perspective and think broader.
I always insist on knowing one scripting language to get things done fast. Scripting works everywhere and these are quick to write and run. (Javascript/NodeJs, Perl, Python, etc).

Art of closing things

If you don’t finish then you’re just busy, not productive. It is important that you finish assigned tasks and have good communication. Not all finishes are a success. Failures are learning that you need to share with others. If something is half baked, make a closer to a logical end with findings noted down. This helps someone else pick it without spending the same time again. One good article I found is: Web Archive: jacksimpson.co/finishing-being-productive-busy/
A mature developer has an attitude towards getting things done. Don’t let a few items drag on your plate without a valid reason. If there are justifiable reasons for something (like not the right time to work, priority changed, no possible solution exists) try to get consensus around it (within a team or with PM) and move the item off the plate. If new unknowns come up, be prompt, share with the team to revise the estimates/delivery days. The bottom line is - without valid reasons, nothing drags on your plate!
Right to say no: Know your right to say no to new things when your plate is full and/or few items are dragging. You just have two hands and one brain. Don’t just take everything to your plate because they are exciting.
It’s okay to work on two or three slow moving items in parallel. This helps to kill boredom and still get things done. E.g. architecture discussion for a new project taking 60% of the time can gel with other small tasks like writing few test cases, following up on existing customer issues, or getting a small long pending bug fixed.

Soft Skills: Communication & Observation

You should observe everything around you, and learn from everything. When you see someone doing something tricky & productive, adopt it quickly.
Learns from code reviews: Code review helps two-way. (a) Review your architect’s code - a question and learn from them, (b) review your peer’s code - argue and learn from the discussion.
Software companies observe transparencies, audit history, group communications, etc. So nothing goes unnoticed. Communicate openly about problems and admire peers for good work. All these shall help in building trust within the team.
Learns from incoming emails about email etiquettes: (a) how to write emails to a larger group, (b) how to politely follow up on pending items and get things done, (c) how to close on long threaded discussions, (d) how to summarize, MoM, etc.
You never say “I am facing compilation errors.” Instead, say “I am facing compilation errors with a file X.java. It appears to be a missing constant declaration.” This conveys that you have spent enough time to know the root cause.
Never say “It’s not my job”. In the companies having specialized teams, there this is quite often to hear. This statement is harsh. Try to share most of the information you have, try to channelize. (You may say this contradicts with - know your right to say no, but all this is an art to deal)
Be open and ask questions, brainstorm casually on small topics with your peers during a huddle.
At the end of the day, meditate for 5 mins thinking what went wrong and what was successful throughout the day.

Search

Remember one thing: you are not alone in the world facing that issue. So, somewhere on the planet, there is another human being who faced the same issue, got the exact same solution which will work for you, and have posted on Internet for others benefit. So, go and find it out!
Knows exactly when to search. When facing an issue, you should know when to reach colleagues or when to jump on a search engine. Something around your product architecture and internal error codes/terms shall not yield anything useful on search engines. (This happens when some root cause is wrapped in product/architecture specific error code)
Never search for just one keyword. Remember to use at least two orthogonal keywords ⟂ . E.g. you want to find that particular email about holidays? Step 1 - remember whom that was from? Step 2 - remember what was it about? Your query should be `from:ankit holiday` as there are two keywords which are perpendicular ⟂, and helps you to reach to the right email.

A 10x engineer (or rock star) should have these qualities, and a mediocre engineer can master at these. The only thing left out is excelling at technical competency which, I believe, will be on fast track to achieve when your focus is on above goals!

References:

Recommended Books: