Quick Tip: How your manager thinks about your seniority

Also published on Medium.

A common thing I tell people who want to progress in their organization is that the best thing they can do for their career is understand how their manager thinks. So let’s talk about how your manager (probably) thinks about your seniority.

Broadly speaking, when we think about people’s seniroty our working definition is “how big of a task can I dump of this person’s head and know that it’s taken care of”.

A junior engineer is someone who can handle tasks as part of a bigger project, but needs someone senior to help them manage their work, break it down and make sure that things are progressing as needed.

A mid-level engineer is someone who can take a reasonable 2-3 months project with a clear definition, success metrics and execution path and get it done.

A senior engineer is someone you can hand over a viable project idea to, and they’ll define it, break down the work and lead a small group of others to accomplish the task. No need to spell out everything for them.

A staff engineer is someone you can throw a vague notion of a project idea at, and before you know it they’ve already explored the potential in it, figured out who the stakeholders they need to align are, defined the success metrics, sold the concept, secured the resources and got initial implementation ready to present to leadership.

From a manager’s perspective, the value of senior employees is that they allow you to have “more plates spinning” at the same time without having to spend extra effort and worry about things progressing smoothly.

3 Simple Ways to Get Your Programming Flow Going

Also published on Medium.

It’s a well known fact in the software world that your productivity as a developer is not linear in the time you spend programming. What this means is that in 4 hours of code writing, you will produce significantly more code than x2 of what you produce in 2 hours of coding.

That happens due to the “Flow” or “Zone” effect. If we are lucky, after coding for a while we go into a “Flow State” where we are uber-concentrated, become one with the code and the loops and conditions stream effortlessly from our brain into the IDE without passing through our fingers. When we are in a flow state we write code faster, better and with less mistakes.

Getting into a flow state is hard, and interruptions and distractions take us out of it immediately (which is why open plan offices are the bane of developers productivity). However, getting into the flow and maintaining it is a mental skill that can be honed, and there are several tricks that help me when I need to do it fast.

Have a Ritual

Rituals are technical things we can do to help our brain quickly snap to a new situation due to the sheer familiarity of the process. I like to:

Move to a quiet location. This is especially important if you are likely to be approached with questions at your desk. If you are a manager, set clear expectation around where you are available and when you need quiet time. Your team should and will survive without you for a couple of hours, I promise.
I like to use the couch in front of the window at the side corridor as my quiet place, so you go and find your own quite space.

Make a fresh cup of coffee. Self explanatory, duh.

Switch off notifications. Your phone should be on do not disturb mode. Close those social media tabs. Close your email client. Turn off browser notification. Seriously, nothing interesting happens there anyway.

Close unneeded windows and tabs. Isn’t it nicer to work in a clean environment? Plus, less chance for distractions and less junk on your RAM.

Remove your shoes. Because how can you write software while wearing shoes?!

Use Mental Reminders

It’s easier to snap back into flow state when you have reminders to where you left off the last time you wrote code.

Draw a design/architecture diagram. I have a notebook of architecture diagrams that I create for my projects. Whenever I need to get back to coding I look at the diagram for the code I am writing and add some details to it, and it helps me to quickly get thinking in design again.

Write where you left off. *Inside your source code*. I have a friend who likes to write inside the source code what he was doing before leaving the office at the end of the day. This way when he comes in at the morning and tries to compile the code, the error messages force him to read the comments and help him pick up where he left off.

Do Some Warmup

Switching between mental states is just as hard and switching between physical states, but where the sports world already realised the trick of using warmups to help these transitions, we keep trying to jump between mental tasks with no adequate preparation and being surprised that we are not very effective at it.

Whenever I start a new task or get back to programming after a pause I tend to feel “lost”, as if my brain is not used to thinking in code anymore. Taking on a simple programming task helps me realign my brain. Here are some simple things I like to do:

Document some code. In them olden days when it was common practice to *gasp* comment your code, I liked to find some pieces of code that weren’t as clear as they should be and document what they were doing. These day I just lightly edit some code to make it self-documenting.

Refactor some code. This is a great passion of mine. I like to start every task by lightly refactoring the code in preparation for the new feature I am about to implement. It’s fun, it helps maintain a high quality code base over time and as a bonus your manager can’t complain that you are wasting precious time on refactoring instead of delivering features.

I like these options because they help improve the project over time, but if you are not excited about any of my options:

Find an unrelated coding task you do enjoy. Coding quizzes? Amazing. Developing a small game? Super cool! Implementing a small feature? Awesome. Anything that gets you thinking in code instead of in human.
Just make sure that the task is well contained and that you are not likely to spend more than ~30 minutes on it, else it will lose the benefit of helping you become more productive in your actual job.

Development Superpower

When a state of flow has such a major effect on your development productivity, being able to get into it quickly and maintain it is a development superpower. It helps you complete your tasks faster and better, makes you more effective at works and leaves your free time to be, well, free.

I’d say it’s a skill worth honing.

The Important Things and WTF is a Technical Vision

One of the more frustrating things for me when I tried to figure out whether I want to be a CTO was reading about the CTO being an owner of the company’s “technical vision”. I had no idea what it meant and I couldn’t find a simple explanation in concrete terms I could understand.

Recently I’ve been spending time thinking about “choosing the important things”. My experience in Hello Heart and my current attempt to found a company made me realise that the choices* you make early on in the life of the company and the product have a very big influence them. For example, a company founded by a biz person and a product/UX person is going to be a very different company than one that was founded by a tech person and an NLP person, even if the problem domain and audience are the same. Similarly, if on the early days on the product you decide that the main technical issues you want to address are development velocity, user experience and high availability, you will end up with a very different architecture than the one you would get if you decide that security, operational simplicity and extensibility are your main concerns.

Putting these things together made me realise that the first and most influential jobs of the CTO is deciding what’s important: what’s important today, what’s going to be important tomorrow and what will probably be important in three years.
This is one of the more fundamental ways in which a CTO shapes the technical vision of a company.

—
* Hint: I am not talking about your choice of programming language. Nobody cares about your choice of programming language.

Geektime Influencers & GeekAwards 2017

Two exciting things that happened in December:

I was featured in Geektime’s list of influential CTOs and VP R&Ds for 2017.
You can read the interview with me there.

I am nominated to GeekAwards (for the second time!). If you want, you can vote for me here. Note that you don’t have to vote in all the categories if you don’t know any of the nominees.

Scala at Hello Heart – Adoption and a Bonus Training Plan

At 2016 I gave a lecture about Scala adoption in Hello Heart.

To make a long story short, while I personally really enjoy the language as a developer, we’ve experienced some problems in getting new developers up to speed. The language seems to be extremely frustrating to learn, even to – and I would dare to say especially to – the most experienced developers.

There are several factors that make Scala particularly hard:

The functional ideas in Scala are still new to many developers. While I don’t think Functional ProgrammingTM is necessarily “harder” than imperative programming, it is a new way to think about writing software. Learning ways to think is inherently hard, and the struggle can be a massive ego blow – especially if you are an experienced developer and expect to just “get” new languages easily.

You can end up with wildly different codebases, depending on the language features you use. The Scala language has many features, and it doesn’t constrain you too much in how you can use them. In a typical project, you wouldn’t use them all at once. Ideally, you would choose the subset of the features you prefer, and stick to them in order to achieve consistent style. This means you can see OOP Java-like style in one code base, functional, almost Haskell-y style in another, and any hybrid you can think of in between. Compare to Java code that is quite similar no matter where you look (a loop is a loop everywhere, as my mom would say).

Scala’s syntax is extremely flexible. Brackets? Which do you prefer? Because we do both. At the same time. Or either. Or none. Semicolons? Yeah you can use them. Or not. Hate dots? You can leave them out! Sure thing! Random punctuation marks for identifier name? Amazing! I’ve always wanted a codebase that looks like it was profanityped by a developer with massive anger management problems and an uncontrolled dirty mouth!

All these properties make Scala extremely fun to write DSLs in. And they do, my God, they do. So not only do you need to learn Scala when you learn Scala, you also need to learn the DSLs of all the different libraries used in your project.

All this brings me to my final point, which is that it is extremely hard to just open a source file and dive into the code. Unfortunately, that seems to be a preferred method of learning in our profession. Try that with Scala, and much hair pulling, curse words and cries for help are guaranteed.

So in order to shorten the learning curve, we created a training program that is meant to take a developer with some experience, and teach her everything she needs to know in order to be productive writing server code in about two weeks.

You can find our training plan here, and watch my lecture here: