Sep 20, 2017

How To Be A Junior Software Developer

How to Be a Junior Software Developer

This article was originally published on ThoughtWorks Insights.


In my time as a junior at ThoughtWorks, I was blessed to have opportunities to grow and develop my skills on several interesting projects, with the help of some amazing people. In this article, I want to share the strategy I used to maximize my professional development. If you’re in a similar position, I hope this will help you make your first steps into tech successful. If you’re a senior or team lead, I hope that this will help you to support juniors in growing and becoming productive. If you’re a company, I hope that this will provide some context for how to hire and staff junior developers.

Learning to learn

I think it’s important to realize that, as a junior, your main value to an employer is most likely your potential, not your current ability. ThoughtWorks certainly didn’t hire me because they thought my technical interview solution should be pushed to production anywhere. So rather than focusing on delivering software 100% of the time, focus on up-skilling. Practice self-reflection and seek feedback to identify your weaknesses. Use whatever resources are available to you to improve your knowledge and skill set. Ask for help from seniors, ask for code reviews, pair program. Understand the context in which you are working - talk to business analysts, QAs, stakeholders, ask questions. Don’t stop moving, cultivate a humble ‘always learning’ attitude. Gain perspective on alternative ways to do things.

Learning itself is a skill that can be developed. I did not join ThoughtWorks with a particularly broad range of technical skills, and so, every project I joined brought a panic-inducing flood of new programming languages, new tools, new frameworks, and new concepts crashing down on me (and that’s not even mentioning business-related skills). These are the moments when impostor syndrome is at its strongest and undermines your self-belief the most. After a while, though, you begin to spot the pattern. It goes something like this:

  1. Enthusiasm
  2. Bafflement
  3. Superficial comprehension
  4. Frustration, having your expectations violated
  5. Working knowledge, productivity
  6. Rinse and repeat

Stage 3 is the most dangerous since in it you’re unaware of your own failure to understand what you’re doing. Better to be frustrated and proactive in seeking help than to cheerfully cook up vats of spaghetti code without knowing any better. Ironically, one can be quite ‘productive’ in stage 3. Get out of stage 3 by seeking feedback on your work and developing a relationship with your ignorance. Embrace it as a temporary given.

Once you’ve gone through this cycle a few times and ended up able to ship respectable production code in a new technology, you develop a ‘can do’ attitude towards learning. You become confident in your ability to pick up new things quickly and start to enjoy it. And, more importantly, you can make a plausible, evidence-based case for this to business stakeholders when needed. I have found that even senior developers sometimes end up lacking this panache because their roles have been too one-sided and have not required them to stretch. So, continuously extract yourself from your comfort zone and put yourself in the situation of having to learn new things - this experience will become your primary advantage as a junior developer, particularly if you work as a consultant. Set the tone for the rest of your career.

Adding value as a junior

Learning is all very well, but at some point, you need to get into the grind and rhythm of delivering software. Apart from your daily work, which will probably involve small and de-risked chunks of responsibility, I strongly recommend that you seek out independent areas in which you can add value to your team and turn them into pet projects.

For example, on my first project, we used C# in the back and React + Redux in the front. Since I hadn’t used any of these before, the barrier to entry to productivity was fairly high. I was lucky to have a tech lead who understood the importance of delegating other useful tasks to me, to keep me confident and productive while learning to use our core delivery stack. In this case, we were using an incomplete open-source build monitor tool for Visual Studio Online, so it became my task to finish implementing it. For context, I had no idea how build pipelines worked, and as it turned out, the monitor was written in Clojure, which has a paradigm that is hilariously different to the object-orientation I was used to. So for a month, I spent my nights producing horribly imperative Clojure code and watching talks by Rich Hickey. By the end, our team had a working build monitor and I had discovered my love of functional programming.

My next project was working on a Java microservices platform using Docker, Kubernetes, and Cassandra. Once again, a new tech stack. This time, I bridged the time needed to get ramped up on the new tools and concepts by making myself useful in the UI. I used my previous experience to help advocate for and execute a migration of critical business flows from Reflux to Redux. This increased the testability of our JavaScript and reduced the complexity of our inherited codebase, which in turn resulted in improved velocity and stability.

In both cases, I needed time to learn and become productive. By identifying things I could do, I was nevertheless able to start delivering genuine value to my teams quickly. These pet projects helped me build credibility and trust with my team and stakeholders, improved my confidence and reduced impostor syndrome, and allowed me to experiment with taking the lead on something (which is a whole world of learning unto itself).

There is always some extra utility to produce or something to refactor. While pursuing pet projects is particularly helpful for your development and team relationships as a junior, it’s a habit that I’ll continue to cultivate. It’s just so fun!

Choosing pet projects

Sadly, there’s no such thing as a free lunch. Like everything, the utility of pet projects comes at a cost. You may be uncertain or confused about where to start. You may not feel supported, or you may feel pressured to deliver functionality. You might be worried about the extra time, work, and effort required.

From experience, I can confirm that those are all real and valid challenges. In addition, expect to be continually frustrated and have your expectations of how things are supposed to work continually violated. To ameliorate these issues, I suggest that you pick projects that:

  • Are small
  • Have clear goals (definitions of ‘done’)
  • Add value/will be appreciated
  • Are likely to be supported once you advertise them (e.g. by team, company, community)
  • Are fun/rewarding in their own right

Moreover, embrace both failure and ignorance. Suspend your disbelief that it will work tomorrow. Suspend your disbelief that you will understand it tomorrow.

And, of course, give yourself time off as well. Taking on pet projects is helpful and fun, but the expectation certainly shouldn’t be that you have to put in extra work beyond what you’re paid to do. Choose to do so when it makes sense for you, and when you have the space for it in your life. You can also speak to your team to see if they’ll allow you time to work on pet projects within work hours, which is definitely possible if there’s a clear value-add.


One of the key tenets of the Agile Manifesto is to prefer ‘responding to change over following a plan’. Continuous Improvement, Continuous Delivery. Produce a version of the product, observe its shortcomings, collect feedback, reassess requirements, produce the next version. Iterate in small chunks, never impose a grand vision based on outdated information. As a junior developer, it’s useful to think of yourself in the same way.

Keep learning.

Sep 13, 2017

My Experience At Nordic.js 2017

My Experience at Nordic.js 2017

I was up in Stockholm last week for Nordic.js and I figured I’d share some of my takeaways. I didn’t go a great job of taking notes, but I did come away with some strong impressions.

MPJ gets a tattoo

The conference was co-hosted by rising star Mattias Petter Johansson of FunFunFunction, which was cool since his show is awesome. The most bizarre moment of the conference came when MPJ randomly decided to get a tattoo and livestream it to the screen instead of appearing on stage towards the end of the second day. Talk about commitment…

There seemed to be a strong focus on diversity and equality on the part of the organisers. Talks were extremely well balanced, both in the gender of the presenters (it felt very close to parity), and in terms of the tech/community balance of topics. The second day also featured an optional “equality pep talk” breakfast to kick off the day. Even the color scheme of the event and the design of the venue seemed to be aiming for gender inclusivity - the palette was dominated by pastel shades and pink was very much in evidence. Of course, the audience was still mostly white dudes by a pretty huge margin, which had some interesting consequences (see notes on Karolina Szczur’s talk below).

Here are my notes on my favourite talks:

The Hilarious Misadventures of Being a Platform Downstream from Your Language

Myles Borins (TC39 Delegate & Google Developer Advocate for Node.js)

Borins is an interesting guy. He has a degree in art and another in music, and has been contributing to OSS on the side forever. He somehow ended up getting hired by IBM to work on Node full-time, and now he’s doing the same thing for Google instead. He was also on Node’s Technical Steering Committee for a while before stepping down in protest in due to the committee’s inaction in a recent code of conduct controversy.

In this talk, Borins described his involvement with the ECMAScript Technical Committee (TC39). The TC39 is comprised of various interest groups, including all the major browser vendors and technical experts (such as Borins, representing Node). They meet once a month in various locations, and it takes a minimum of four meetings to get a new feature approved. You need a full spec, an implementation in a major browser, as well as total committee consensus to become part of the standard - this is why it takes so long for new features to enter the language. Going to these meetings is expensive (voting members pay USD 70,000 per year) and essentially a full-time job for feature champions, who have to take on the role of developer, manager, and diplomat all at once. This bars most JS community members from impacting ECMA directly, but you can assist the champion for the features you care most about, e.g. by writing tests, working on the spec, etc.

Best Practices for Reusable UI Components

Mars Jullian (Netflix)

Netflix is apparently betting heavily on UI component libraries that can be shared and reused between teams. Jullian had a key role in developing their approach to this, and she kindly shared her key takeaways:

  • Use React for your libraries. It’s easier to repurpose for other frameworks than vice-versa.
  • Your component should physically begin at its visible edge (i.e. no margin or border, potentially no padding)
  • Enough local state to work an an independent unit
  • Tightest possible type-checking on props (including object/array shapes)
  • Fewer props - make the component easy to understand and reduce cognitive load. Use smart rendering instead of extra props - e.g. don’t render a list if the prop comes in as null or empty instead of passing an additional shouldRenderList prop
  • Pass specific props to children; don’t blindly pass on all props (since this would allow unintended behaviour to be applied to children from the outside)

Reactive Web Animations with RxJS

David Khourshid (Microsoft)

As a functional programming buff and ReactiveX enthusiast, this was awesome. Not only does Khourshid have wicked UI skills, his reactive model of animations really makes a lot of sense. He demoed an observable model of animation-triggering events using RxJS, which could then have all the usual reactive transformations applied to them, such as merging, mapping, filtering, before yielding the desired visual effect.

The coolest thing? With this approach you can unit test your animations as pure functions!

Beyond the Bubble

Ben Schwarz (Calibre)

We need to stop optimising for $3000 MacBooks. We set out to build the world wide web, not the wealthy Western web.

While we think of performance as less and less relevant these days, this is a very biased and unrealistic point of view. There are tens of millions of first-time internet users entering the market every year in India alone, with the vast majority being mobile-only. These users do not typically enjoy the latest/most performant devices, nor the fastest connections, nor the cheapest data plans. So slow/large applications can be crippling from both a usability and financial perspective.

The most critical information, such as main text content, should be available instantly, independent of styling and interactivity status (e.g. if you visit The Guardian’s site with JS turned off, you should still be able to read the news). According to Schwarz we need to be paying particular attention to load order here, particularly with webfonts, which get loaded lazily (only when text tries to be rendered that wants to use that font). Single page apps, which require all JS to have been downloaded, processed, and run in order for text to be rendered, can cause quite a delay for a webfont to be loaded and text to be displayed.

In these cases, we can play around with load order using the preload tag (and I suppose you could come up with some server side pre-rendering solution, too). In any case, “time to first paint” and “time to interactive” should not be the same thing. We can keep ourselves honest by doing regular, realist perf audits using the the excellent Chrome devtools and mediocre (realistic) devices.

Who Cares Why Undefined Is Not a Function

Tereza Sokol (NoRedInk)

Can essentially be summarised as “Elm’s pure functional approach and solid type checking gives you back the time you waste looking for the cause of unhelpful JS error messages”.

Sociolinguistics and the Javascript Community: A Love Story

Harriet Lawrence (Buildkite)

Coming from a dev background, Lawrence is a technical writer at Buildkite, a CI tool maker based out of Melbourne, Australia. She’s also currently getting her Master’s in Sociolinguistics, focusing on tech communities, so she’s got a real passion for and deep knowledge of the intersection between language and culture, particularly in the tech space.

I would summarise her message as “words matter”. The way we talk about our work and communities in public forums (e.g. Github) can really make a difference in how likely outsiders are to join and feel empowered/valued, and how likely existing members are to continue contributing. In addition to obviously not being an asshole, Lawrence suggests that we can create productive environments by creating a community that accepts weakness (e.g. by tweeting something like “this thing was really hard and I thought I’d never get it but hey, looks like I’ve learned something”) and that recognises effort and progress (e.g. merging a PR from a new contributor by saying “nice use of technique X, you’re really getting the hang of this tech stack” rather than “cool, merged”).

Chatting with her afterwards, I asked her about what to do when someone just refuses to accept that their behaviour/language matters or has an impact on the community, since this seems to happen a lot (see Node’s recent code of conduct debacle for an example). She told me that there are some people who will just never be persuaded and have that empathy, and that these people will sadly keep creating a toxic environment for others. In those cases, Lawrence says that nowadays she just stops working with the individuals in question.

Building Inclusive Communities

Karolina Szczur (Developer, designer & conference organizer)

This was a very well-done intro to privilege, diversity, and inclusion. While I personally didn’t hear anything particularly new here, it appeared that the topic was new and uncomfortable to quite a few audience members. A number of people got up and left during this presentation, and while I can’t say for sure, it did seem to be only men who did this. Afterwards, Szczur tweeted an email she received from a male conference attendee, saying that he felt discriminated against, remarking that “this is not Trump’s America”, and claiming that “we don’t have [gender inequality] in Sweden”.

Clearly we still have quite a way to go, but well done to Karolina for meeting the exhausting task of educating.

May 5, 2017

Migrating From Reflux To Redux

Migrating from Reflux to Redux

I recently helped my team move a large codebase from Reflux to Redux (I have written exensively about my experience on ThoughtWorks’ Insights blog). Both are JavaScript-based state-management tools. This was an interesting technical challenge, and a fun one.

Because Reflux and Redux both follow the basic Flux architecture pattern of unidirectional data flow, we can incrementally take over the Reflux state cycle with Redux:

  1. Complete Reflux cycle
  2. Action handling (e.g. async) in Reflux, but keep all state in Redux. Reflux store action listeners dispatch Redux actions with the results of remote API calls and no longer call this.trigger. React components receive props mapped to Redux state and no longer listen to Reflux stores. At this point, Reflux essentially acts as async middleware for Redux.
  3. Action handling (e.g. async) in Redux, with appropriate middleware. Reflux store action listeners now do nothing but straight away dispatch corresponding Redux actions.
  4. Complete Redux cycle – stop dispatching Reflux actions from React components and start directly dispatching Redux actions.

Redux Migration - Technical Diagram

Thus, you can break the refactor up into bite-sized chunks and spread it out over time if required (e.g. due to other high-priority work/new scope coming in), keeping your app fully functional at every stage.