Compound interest in your career: how use the power of the environment to accelerate your professional growth

Over the last week I’ve been reading Judith Rich Harris’ The Nurture Assumption, where the author exposes the idea that children are not so much influenced by their parents as they are by their peers. Most examples Harris gives us during the book show that the environment in which children grow up is a lot more powerful in socializing them than their parents. Despite best intentions for getting children to behave in certain ways at home, the world outside and other children are the key to derive their social behaviors which might or might not impact their adult lives.

This got me thinking about a very simple observation from the workplace. Put mediocre engineers in a team of great engineers and watch them grow. Seems obvious once it’s stated like this doesn’t it? And yet how many people forget about this simple principle when applying and choosing a job?

Let me elaborate a little bit on this last rhetorical question. Imagine you’re looking for a new job and after some arduous code tests and technical interviews you finally have a couple of offers in your hand. As a software engineer you want to work with a hopefully recent and great technology (whatever that means for your particular industry and interests), get a nice salary and work on challenging products. These are the most common requirements when thinking about a job offer.

  • What technology do you guys use?
  • How much am I going to get paid?
  • What will I be working on?

These are the typical questions I hear from candidates in interviews. A surprising small number of candidates ask the question “What does your team look like and how do you work together?”.

The reason why that is surprising to me is that working in a team of great engineers who put the focus on sharing knowledge, helping others and educating the team has the same power as essentially compound interest for your career. In other words, it’s a snowball effect disguised in plain sight. Tools of Titans’ author Tim Ferriss already said that you are the average of the five people that you spend more time with. I’ll propose here that you should be using that when it’s time to choose a job.

Let’s think about this for a moment by examining each one of these questions in more detail.

If you take the job with the most recent technology does that guarantee you’ll grow your career, become smarter and get more money in the long run? Maybe. That’s the honest answer. Technologies come and go and in a software engineer’s lifetime you’ll probably end up working with dozens of programming languages, frameworks and techniques. Do you want to bet your career in Angular’s success? What about Spring? Should you be the .NET MVC guy? I’ll grant you specializing in a particular technology could allow you to surf a wave of clients and projects for as much as a decade with great return on investment, especially if you work as a consultant directly for clients, taking out agencies and other services middlemen. Bur surely you can’t be thinking in realistic terms to be using this 15 or 20 years from now and counting on it to pay your bills?

Speaking about bills, what about money? Surely you can’t be saying that I shouldn’t take the highest paying job, all other things being equal. Again, my answer will be maybe. It will depend a lot on which phase of your career you are, on your own personal goals and just responsibilities. Maybe you have a family that depends on you. Maybe you want to make a big investment in a couple of years and you need to save some cash for that. The point is, this will be a contentious answer no matter which way I put it. The reason why I’m bringing it up then is to give you an alternative view to the common position, which is just taking the highest paid offer. What about taking the offer where you’ll be working on more difficult challenges? What about taking the offer where you’ll be working with a great team? If you apply some long term thinking to this, and taking some numbers to illustrate this example, you might be refusing company’s A 50k offer to go work with company B on a 40k offer that allows you to grow at 4x the pace you would in your highest offer. Presumably you will be adding much more value in a year or two at company B that the managers will have no choice but to promote you. The worst case scenario on company A is you being tied down to a 50k+ job in 2 years time without any real options to grow from there. The worst case scenario on company B has you not being promoted by the managers, still making less money than on company A but with confidence and skills to command higher offers from other companies, should you decide to leave. Of course this is dependent on job markets, but just for the numbers themselves. Value is value, no matter what part of the globe you are and if you add value people will jump at giving you opportunities (and money to go with them).

The last of our three questions has to do with what will you be working on. This one is probably one of the most relevant for me. A good product can help you learn a lot about software architecture, design and patterns. Working with legacy code bases, while not pleasant for the most part, could provide an opportunity for relentless refactoring, assuming quality checkpoints such as automated regression testing are in place. Again, the answer here about your career growth being tied directly to the projects you work on is maybe. The project can go horribly wrong and yet you learned so much from it that you have a newfound confidence about tackling other challenges in the next project. The project can also be cruising along well and you can be working on maintenance with very little emphasis on actually improving the product. And this will have me jump straight into my last question and the one that I consider to be the most important one to ask.

Who do you think will have the better chance of becoming a great software professional in the long run, the developer who ended up working with his favorite technology, in a challenging project by himself (and making more money in the meantime) or the developer who had to learn something new from a great team that put time in to teach him and offered so much advice on how to write code, design practices and architecture that he now can teach it himself?

I truly believe it’s the second. Great teams make great software. And great teams are hard to come by, but that doesn’t mean they don’t exist and surely it doesn’t mean you can’t ask about them in a job interview. The environment around us plays a huge role in shaping everything about us. A smart coder turned loose in a team that plays along well with anybody will transform him, one can say 10x him, to use the famous 10x metaphor. Humans are a social species and as such, it’s only natural that we learn from others. I can definitely see great developers ending up in crappy (or non existent) teams, working in recent technology stacks and what it just brings them unhappiness. Unhappy developers are not productive developers. And developers that are not productive don’t learn as much, which directly translates into career stagnation.


Stretching to learn by yourself is a great strategy for growth but it doesn’t beat working 8 hours per day in a team that throws so much feedback and knowledge at you that by the time you realize it you are the equivalent of a veteran in your lone wolf friend’s company. Bringing it back to the idea of compound interest, your learning, your drive to excel, that is the principle. We can assume it will grow linearly throughout time. What you learn via your team, that is the interest that you get and this will grow exponentially. The key to accelerate your career growth is then, counter-intuitively, to give it to others around you and not focus on it yourself too much. Think about it the next time you’re interviewing for a job and who knows, you might just 10x yourself in a couple of years.

How to create a blog using GitHub Pages and JBake

Recently I was looking into creating a blog in order to write down some thoughts. In looking for simple ways to create one, but being a bit more technical than the average user, I started by discarding Blogger, WordPress, Medium and the like. I wanted to keep content under my control (let’s pretend for a second that GitHub is under my control) and still have a workflow that allows me to write, save and publish with simplicity and flexibility.

As a software engineer, a very simple solution that I found is using Git, which I already use on a daily basis for development work.

So without further ado let’s get started with the details of what we need to get writing and publishing.

GitHub Pages setup

The first step is creating a regular GitHub account. There is nothing fancy here and I will not go into any details on how to do this, although it should be pretty straightforward.

Once you have your repository created you should install Git locally in your machine. It’s worth mentioning that the repository name must obey the rule where username is your username on GitHub.

After you have Git locally set up you can clone the repository by copying the clone URL of your repository GitHub page and using it on your terminal.

$ git clone

For user repositories GitHub Pages requires that you put your site in the master branch. For project repositories, you should use the gh-pages branch. For the remainder of this article, we’ll assume we’re interested in creating a page for the user and so we’ll use the master branch.

GitHub Pages will pick up whatever content you have in the master branch and it will serve it in the **** URL. This means that if you just add a simple HTML document to your repository, you instantly get a page on that URL. Despite not being extremely interesting it’s a start.

Domain setup

If you have a domain name bought and paid for you can use it to point to your new page with some more configuration steps that I’ll explain now.

You’ll need access to your hosting provider (e.g. GoDaddy) typically to your control panel like cPanel or a custom interface. Here you need to add a CNAME or A record, depending on your goal.

The first step is creating a file called CNAME and adding it to the root of our repository. On this file, the only thing we need to add is the domain name we’ll be using to access this site, for instance

After having this file in place in the repository, we go to our hosting provider control panel and we look for the option to zone records or alias. Here we’ll add a CNAME record with pointing to the subdomain that we want to use like or If we want to use the actual top level domain we’ll need to add an A or ALIAS record for to and another A record also for to These IP addresses belong to GitHub and are subject to change (they have changed in the past). Typically GitHub help will contain articles on the latest IP addresses that you should use so check here for the latest news on this.

You can quickly check that the domain is correctly set up by running the dig command online here. You should see something like this:    14399    IN    CNAME        14399    IN    A        14399    IN    A

JBake setup

JBake is a great project that takes the Jekyll static site generator and brings it to the JVM world via Java. JBake allows us to edit pages using HTML, Markdown or AsciiDoc, process these pages with templates defined using Freemarker, Groovy or Thymeleaf and style them using CSS frameworks such as Bootstrap or Foundation.

Jekyll is what GitHub Pages actually uses behind the scenes to serve the content that you are uploading to the repository. If you want to use Jekyll locally you’ll have to install Ruby and RubyGems. In order to use JBake you’ll just need Java 6+ and since I’m quite lazy and I happen to use a Java/JVM environment on a daily basis I decided to give it a try.

We’ll start by going to the JBake website and downloading the latest release. Unpack the zip to a location of your choice and add that location to your Path environment variable so that we can launch JBake from any location.

Now let’s take a look at the structure of the site with JBake. I’m borrowing the structure from the official documentation to exemplify:

|-- assets
|   |-- favicon.gif
|   |-- robots.txt
|   |-- img
|   |   |-- logo.png
|   |-- js
|   |   |-- custom.js
|   |-- css
|   |-- style.css
|-- content
|   |-- about.html
|   |-- 2013
|   |-- 01
|   |   |-- hello-world.html
|   |-- 02
|   |--
|   |--
|-- templates
|   |-- index.ftl
|   |-- page.ftl
|   |-- post.ftl
|   |-- feed.ftl

On the assets directory, we have the typical static files that we’ll need to load the pages, such as CSS, JavaScript and image files. Usually, we’ll edit this folder once at the beginning and then let it be unless we’re adding a new JavaScript library or editing our CSS in order to get a new look on the site.

On the content directory is where we will keep our data that will be used by JBake to craft the site. This is where we put our HTML, Markdown or AsciiDocs, which means this is where we’ll spend most of the time after our initial setup. After all, the whole point of this is getting us to write more and spend less time fiddling with the process of publishing.

On the templates directory, we keep the template files to edit with the language of our choice. Below I have a simple example in Freemarker for the post page that comes with JBake.

<#include "header.ftl">    
    <#include "menu.ftl">    
    <div class="page-header">
        <h1><#escape x as x?xml>${content.title}</#escape></h1>
    <p><em>${"dd MMMM yyyy")}</em></p>
    <hr />    
<#include "footer.ftl">

We can easily create an example site by issuing the command

$jbake -i

It’s very useful to run this command the first time as it will provide us with the structure that we can then adapt to our needs. Finally when we have some content and we are ready to generate the site we can do

$jbake -b . blog

This will generate the site from the root of the repository and put it into the blog directory. Bear in mind that the blog directory will be overwritten by this. An easy way to bypass having to issue this command to generate the site with the source and output directories is to configure the default in such as


Having configured this, we can just do $jbake -b from our root directory.


Now that we have the site structure in place a typical workflow for me goes like this:

  • Pull the latest code available because I’ll use multiple laptops to work on. I’ll do this with $git pull origin master or any other branch name that you might be working on.
  • Navigate to my content directory and create a new file for a new blog post. This usually takes the form of year-month-day-post-name and I’ll usually write in Markdown which is starting to become ubiquitous.
  • Save the work on and commit it with git commit -m "My message.".
  • If it’s a work in progress then we have two choices: either I’ll push the commit to a branch different than master and later when it’s finished I’ll merge that branch or I’ll push it to master now but I’ll keep the header options of the post as status=draft. In the latter, I’ll then change the status to status=published when I’m done with the blog post so that JBake will pick it and publish it.
  • Run the $jbake -b command, pushing the content to the remote repository and see it published.

Here are the links for the official documentation. Go explore!

JBake Documentation –

Freemarker Manual –