On becoming a software engineer

My mission over the next couple of years is to become a software engineer focused on developing modern full stack JavaScript web applications. What follows are my reasons and a roadmap to getting there.

Why become a software engineer?

Over the past few years I’ve had a chance to build software that people use day to day to make them more effective. There’s three points during the software development lifecycle where magic happens;

1. Understanding and shaping (e.g. through iterating) what the end-user needs and wants and the appreciating the difference between the two
2. Designing and coding. Solving the technical challenges. There’s a raw satisfaction in seeing your idea, which started as a thought inside you, born in the real world. There’s phases where you must breakthrough things you didn’t know or understand and when you do, there’s a step change in your understanding. You might sit there and say “wow, that really worked?”. I’ve said it out loud at work before, it’s a great feeling.
3. Delivering software that makes a difference. In many ways the software engineer or business analyst will never understand the pain of the end-user unless they are the end-user. They may intellectually understand the problems they’re trying to solve e.g. it takes an hour of repetitive work to do what could be done in 2 minutes, but to day after day watch those 58minutes of your life pass you by only the end-user has internalised that feeling. And only the end-user understands what it feels like to be given those 58minutes back. You get a fraction of their joy through a high-five or even a simple sincere thank you, and that’s a lot.

Lifelong skills. Whilst software engineering is a financially rewarding area of work because the skill set is in demand, will it always be the case? It may be that typical web development projects become ‘solved’ (e.g. there’s an established framework for that e-commerce app) and the engineer becomes the modern equivalent of a factory operator (e.g. a low cost contractor on Upwork), soon to be superseded by other software. I think we’ll see some interesting shifts over the coming decades with IoT (Internet of things: interconnected devices) playing a central role in our day to day connected lives. People will program not just silicon boards on computers but synthetic issue on biological systems (Bryan Johnson‘s labelled his investments in core areas like this the OS fund) so we’ll see the overlap between disciplines such as natural science and computer science. Therefore I don’t see there being less opportunity in the future, I think there’ll be more but it’ll branch off in areas unclear today. The modern engineer will have to identify, understand and adapt to the shifts they see in their communities so the idea of professional (and personal) growth is embedded into what it means to be a software engineer.

Why web applications?

I don’t mean for this to come off as web vs native (I intend to develop native, mobile apps too at some point). Rather, I want to show the breadth and depth of web applications in general.

App distribution. Being able to share a link with users and not worry about their operating system nor ask them to install additional software is a major boon. There might be differences between how things appear and work across browsers but I see this gap closing and there’s tools to help you identify when you’ll run into compatibility problems.

The browser is the window to the device’s soul

Reach. The browser is the window to the device’s soul. Designing web apps responsively, your app can run and look good on large desktops, tablets, to small screen mobile devices.

Native capabilities. We’re seeing companies like Microsoft support JavaScript libraries which allow the developer to tap into the native capabilities of the PC. W3C have standardised and specified the access to core mobile features such as the Geolocation API. Whilst there’s still a gap between the features you can access natively and via the web, e.g. the W3C’s discontinued attempt to specify the Contacts API, we see bridges between the two such as Apache Cordova allowing access to contacts, pictures, etc. Therefore the web app developer will have at their fingertips access to a breadth of features; both web and device specific.

Performance. The success of subscription based business models e.g. Software as a Service, is in part a testament to performant web apps. Consider Google docs; the user experience is robust and it’s available offline – it’s replaced the office productivity apps on my Mac. In fact Google’s ChromeOS is an entire operating system geared around web apps; always up-to-date. Even services traditionally associated with desktop processing such as batch image resizing, file conversion, large file distribution are supported through web apps; I use them as tools I dip and out of. There’s still a gap between the performance of native mobile apps and web apps running through the mobile browser. Perhaps the gap can be reasonably bridged through frameworks such as Ionic. Where performance is paramount and you have the resource, develop that native app but you’ll probably still be calling services delivered through a web application’s API.

Why JavaScript?

I’ve programmed in a few different languages (strongly typed compiled object oriented such as C#, dynamically typed scripted such as PHP, etc.) and I’d like to try others (C, Haskell, etc.) so this isn’t a question of only learning JavaScript but more so, to specialise and become an expert in JavaScript. JavaScript is to the web what English is to programming, the dominant language.

JavaScript is to the web what English is to programming, the dominant language

1. Reach. It runs almost everywhere; client side (mobile and desktop browsers), server side (e.g. node.js) and I think it’ll become the de facto standard for IoT devices and robotics (e.g. Johnny-five framework for platforms such as Arduino) which will become increasingly important over the next decade.

2. Front-end development and tooling. While on the backend you might have the luxury of working with a strongly typed compiled language because you and your team have chosen a particular stack which supports it, you don’t get the same choice on the front-end. For most cases the only thing you can assume is that your user will support JavaScript. It’s safe to say that the spec writers at W3C won’t decide to rewrite their JavaScript APIs in another language let alone browser vendors implement another language in a hurry. Rather what we see is JavaScript itself evolving (and at a faster cadence) e.g. ECMA announced the first major update to JavaScript for 6 years in ES2015 (or ECMAScript6). Going forward the spec writers will look to the community to identify what to bring into the language; of the frameworks and libraries people are using today, what should we abstract and provide? What all this boils down to is that if you and your team want to create maintainable web applications for at least the next several years you’ll need a JavaScript framework, it may be a popular open source framework e.g. AngularJs, Ember, Backbone, React, etc. or one you and your team develop in house.

3. Flexibility. JavaScript supports many programming paradigms including object oriented, functional (e.g. PureScript), and event-driven (on client side and on the server side via node)

Why full stack?

A core part of learning to develop modern web apps is to understand the workings on the client and server therefore the apps I’ll be building over the coming months will be full stack. I’ve done both client side and server side development on different projects and enjoyed both. Frameworks like Meteor are even blurring the lines between client and server – that’s a framework I’ll be writing a prototype app on.

Even if professionally I specialise in front-end development, I’d still want to understand and see the whole picture e.g. both consuming APIs and understanding their design. With web app designs such as SPAs (single page applications) we’re seeing more responsibility being placed client side e.g. whereas in the past we may have had the server rendering the View (HTML), now the client typically requests data asynchronously from the server and handles rendering itself, so if I were to specialise it’d likely be front-end.

The roadmap to becoming a software engineer

1. Become very clear on the “why”. There’ll almost certainly be days where I’ll struggle and doubt my ability, and want to take the path of least resistance, but on those days I’ll reflect on my reasons written above, and my reasons will remind me why I’m carving out this life.

He who has a why to live can bear almost any how – Nietzsche

2. Commit completely. I’ve traded the comfort of a regular paycheck for time to develop and self-educate, to retool. I don’t have the luxury of saying I’m too busy to pursue the life I want to live – I’m giving myself the best chance by taking a calculated risk and removing the obstacles.

Children don’t learn language faster than adults, they’re just put in a situation where they have to learn. Adults have jobs and mortgages – they can’t commit in the same way – Tim Ferris

3. Build a ‘self-designed university’. In his book On Becoming a Leader (which inspired this post’s title), Warren Bennis describes how Marty Kaplan was able to succeed as Vice President of Disney Production without a background in the movie business:

Before starting this job, I put myself through a crash course watching five or six movies every single day for six weeks, trying to see every successful picture of the last several years. Then I read as many scripts as I could get my hands on, to see what made these particular movies great. I kind of invented my own university so I could get some sense of both the business and the art. … It became clear to me there were about one hundred core writers and I systematically set out to read a screenplay or two by each of them. … One thing I did when I first got here was to sit in the office of the studio head all day, day after day, and watch and listen to everything he said or did … I had a yellow pad with me, and all through my first many months, any phrase I didn’t understand, any piece of industry jargon, any name, … I would write down, and periodically I would go trotting around to find anyone I could get to answer. – Marty Kaplan

Now consider the resources available for anyone to tap into today; code shared and discussed on a massive scale at Github, direction on technical knowledge to develop from Google, technical discussions on Quora, Hacker News, Stack Overflow, top universities and educators are opening up learning online at edX and YouTube, and people are getting together regularly to talk about technology and development at Meetup.

There’ll be six pillars to my self-designed university; Practice, Education, Community, Mentorship, Experience, and Reflection.

The first three years

1. Practice: building web applications for real humans solving real world problems. Whether that means I’m the only end-user or it’s a friend, the apps will be actively used – I want to learn not only how to write quality maintainable code but also delve into design thinking (create an app spec and question assumptions – will what I build really solve the problem or throw up new ones?) and deliver a good user experience. This is where most of my growth will happen in the first several months of 2016. Since each of these pillars will have measurable goals assigned to them in due course, the first app I’ll build, called LevelUp, will be responsible for easily tracking these goals. Live progress on my goals will be fed back to the goals page, making the general public my accountability partner.
2. Education: learning through instruction e.g. online courses such as CS50, MongoDB and the MEAN stack, listening to technical Podcasts such as JavaScript Jabber to stay current on modern technologies, Start Here to understand the web dev industry better, and The Psychology Podcast to better understand individuals and groups and therefore end-users. Courses will typically be used to get a flavour of a technology, and this knowledge will feed into the Practice pillar where an app will be developed based on it, combining the theoretical (or practical but unapplied) to the real world.
3. Community: understanding where technology (web applications, key open source projects) is today, the people who’ve pushed it forward over the past several years and how and why they’ve done it. Just as Marty Kaplan identified the core writers and read a script or two by each one, do the same, read code and blogs by core influencers in modern web development. Fortunately there’s a breadth of developer communities in London so Meetups centred around the modern web and JavaScript such as Node.js, Angular.js, React, and Meteor are easily accessible allowing me to meet people within the community face to face and keep my ear to the ground on the latest developments.
4. Mentorship: seek out and develop productive relationships with a few experienced engineers or leaders. Mentors will play a role at the operational level of getting unstuck whether that’s through coaching or technical guidance. They’ll have an impact, perhaps indirectly, at the strategic level too; understanding their distinction of what is important and unimportant, and how they see the world differently to me, broadening my perspective.
5. Experience: work professionally as a software engineer. There’s things you learn on the job which can’t be learned otherwise; working as part of a team – successfully meshing differences in personality, outlook, technical ability, communication to create great software, osmotic learning (learning through just being around engineers more experienced than you – the language they use, the problems they solve and how they solve them, typically unearthing best practice), estimating and managing workload, and the understanding relationship between the developer and customer, and internal teams such as marketing and finance. This is where most of my growth will come from, starting Q1/Q2 2016, though I am yet to apply to companies (if you are hiring a web app developer around this time, please get in touch @MandaliaKunal on Twitter)
6. Reflection: just as Marty Kaplan wrote on a yellow notepad the things he didn’t understand at the time but had to learn, do the same and publish the key questions and lessons here and perhaps on medium too.

After three years

This is typically the time a junior developer becomes a mid – senior developer. Whilst it becomes increasingly hard to predict what will happen next, I’ve noted some of the things I’d like to accomplish by this time. Generally the focus shifts from learning the ropes to helping others learn. The Pillars have matured:

1. Practice: having been building apps for a few years, author a portfolio of 15 or more actively used apps with real end-users.
2. Education: continue learning through online courses and Podcasts. Share your knowledge by creating at least 2 educational YouTube series on topics in web development
3. Community: host at least 1 group Meetup related to modern web apps. Contribute to at least 2 open source projects.
4. Mentorship: continue to seek out mentors if you want to move into other areas. Be observant to junior members seeking a mentor and be the mentor at least 1 person.
5. Experience: determine the professional trajectory over the next few years; to stay at the existing company, to become a consultant and work project by project, to found a start-up, or to do something quite different.
6. Reflection: have writing as an engrained habit – write at minimum once a month, from the web to other areas of interest like Psychology, Investing, and Personal development

These Pillars now each need measurable, meaningful goals to turn this roadmap into something that’s actioned day by day, through dedicated, scheduled slots of time, to form the habits that are necessary for me the carve out the life I want to live. My goals and real-time progress will be viewable here once I’ve developed LevelUp to track my progress.