Skip to content

Instantly share code, notes, and snippets.

@Najaf
Last active February 16, 2018 19:00
Show Gist options
  • Star 19 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save Najaf/23fa0b33599bcf3d3035 to your computer and use it in GitHub Desktop.
Save Najaf/23fa0b33599bcf3d3035 to your computer and use it in GitHub Desktop.

Training Day

We spend one day a week, (currently Friday's) on "self-directed training". The following is an explanation of why we have training day followed by some ideas for what to learn and how to spend your training time productively.

Why we spend time on our skills

There are many mutually reinforcing reasons why I want us to set aside so much time to focus on our skills.

From the point of view of pure greed, by hiring smart people and commanding them to upgrade their skills, my employees get demonstrably better at their jobs every week. The skills you build will be put to work for our clients and on any internal work we do. Your value to the business is directly correlated with your ability to do things. If you can do more things better this week than you could last week, you are by definition more valuable to the business. And I don't mean some vague definition of "value" that includes e.g. how you make people feel or what "diverse perspectives" you'll bring to the company. I mean there's a dollar value attached to you and it goes up with every minute you spend improving you technical abilities.

Everyone's skillset is patchy. You may have plenty of experience of low-level systems programming but only the basics of SQL and relational databases. You can know the Ruby object model inside-out but still only have a superficial understanding of the Rails view layer. Maybe you understand the Rails stack from TCP socket to rendered markup but are lacking in front-end development skills. Perhaps you've been a web developer for more than a decade but haven't quite got around to fully understanding web security. Whatever skillset you have, it's probably good enough to get you hired (it got you hired here) and be a mostly productive developer. On a long enough timeline however, you will have to make intelligent decisions that require knowledge of these topics in your day-job. Most of us have to spend time outside working hours to patch up our skills, if we do so at all. Your one day per week of training is an opportunity for you to patch up your skillset. Search your feelings. What do you feel bad about not knowing enough about? Training day is there for you to take your imposter syndrome and turn it into uninhibited competence.

Happy Bear Software is a young company. We make money by selling consulting and training services. One we'd day like to launch our own products. We don't really know what those products are. There's another company that was once perhaps like us. They had an employee that wanted to quit to work on a side project. The company convinced him to stick around by offering to pay him to work on his side project. The company I'm talking about is Squad and the side project is Kerbal Space Program, which turned out to be massively successful (and a hell of a lot of fun to play). Whether you decide to experiment with games programming, digital signal processing, cryptography, natural language processing or a simple SaaS application, we're 100% open to the idea of turning your training projects into products or services. Your training projects could fundamentally change the direction of the business.

Deep learning takes time. You can get a brief overview of a topic by skimming an introductory article, but developing useful abilities takes time and concentrated effort. You'll probably need a few uninterrupted hours with a notepad and pen along with a terminal window to try out code. It's very difficult to squeeze this in around a full working day. Even when you do have a few hours set aside, it's rare that your first attempt at learning even the basics of a new topic result in any meaningful progress. To break through you'll likely need to make multiple attempts spread out over a few months. We spend an entire day every week on training so you have ample time to make meaningful improvements to your skills.

This company is the people that work for it. It happens to be a fact of nature that skilled developers are extremely difficult to come by. We want to work with developers who can teach themselves new skills and are motivated to do so. It's self-evidently true that to attract developers who want to upgrade their skills we should offer the time and resources to upgrade their skills. I see training day as absolutely intrinsic to the business, but from the outside it looks like a "perk" to lure other developers in. That's fine by me because training day attracts exactly the sort of developers we want.

You're a developer today, but there's no telling where you'll be three, five or ten years from now. You might decide to aim for a CTO or technical lead position at a startup. You could become a freelancer or consultant in your own right. You may team up with an entrepreneur and become a technical co-founder or even start your own VC or self-funded startup. Whatever you decide to do, building credibility and visibility among people in the software industry will help. By doing things like contributing to open source, writing blog posts and preparing talks on training day, you get the added benefit of increasing your personal profile. You position yourself as an expert in whatever you're working on. That makes the company look good by association.

In summary, the reasons we spend an entire day per week on improving our skills:

  • As an employee, it increases your value to the business.
  • It gives you time to address gaps in your skill set that you'll need to fill for your day-job.
  • If you want to turn your training project into a viable business, we're all for it.
  • We spend an entire day per week on training so you have time to make meaningful improvements.
  • Having a weekly training day helps make other developers like us want to work here.
  • You get to improve your professional profile, building credibility and visibility for yourself and for the business.

I hope by now I've convinced you that it's a stonking great idea, both for you and for the business.

Topic Suggestions

You should first and foremost pick whatever you feel is the most important thing for you to work on next. The following is just a list of suggestions in case you need a little inspiration.

Prefer the old to the new. Learning PostgreSQL or git in depth will be far more useful to you than the latest JavaScript framework or NoSQL database. If those new tools really are as good as they seem then they'll be around for you to learn in five years time (at which point they'll be old tools). Old technologies that you use every day have proven themselves over the long haul, so you can't possibly waste your time when learning them. You may feel you're missing out on the "cutting edge" by not learning the newest tech when it comes out. In practice you're probably not missing out on much.

In no particular order, some things you could be spending time on:

  • Rails. Rails is our weapon of choice for delivering web applications. The better you know it, the better the software you deliver with it will be. If there's a part of a Rails API you've always been a bit sketchy about you could dive into the documentation and build a stronger understanding. If you're not sure how Rails works internally then it's time to crack open the relevant gems and see how it hangs together. If you have no idea how a routing layer could possibly work, then you might instead want to spend time building a small subset of the functionality Rails gives you for a basic rack application (you could do the same for an ORM, a templating layer or any other part of Rails). You could take a look at recently added features to Rails (e.g. Rails API) and see how you could put them to use.
  • Ruby. We use Rails so much of the code we write is in Ruby. If you're not sure how in the object model works then you could work through the PickAxe book or The Well-Grounded Rubyist to fix that. A fantastic use of your time would be to spend it with the documentation of bread and butter classes like Array, Hash, String and Object to see if there are useful methods that you hadn't heard of before. If you'd like to get a taste of the internals of Ruby then an attempt at reading the code of the MRI itself might help. If you're more interested in learning about object oriented programming, TDD and organising your code there are endless resources available for you to work through.
  • SQL and relational databases (PostgreSQL in particular). All of the following would be extremely useful to use and understand:
    • Basic understanding of theory underpinning relational databases
    • SQL for CRUD
    • Inner, outer, left and right joins
    • Subqueries
    • Triggers and constraints
    • ACID and how it's implemented in PostgreSQL
    • Indexes, when to use them and how to see if they're being used
  • Browser markup and scripting (HTML, CSS and ECMAScript) HTML and CSS are quickly adding new features that get adopted by modern browsers and it's important to keep up to date. You can do this by reading the relevant specs and researching which browsers have implemented what features. JavaScript and modern techniques from using it are also worth your time as for better or for worse, we're going to be using it to script browser interactions for the foreseeable future.
  • Technologies that underpin the web (TCP/IP, DNS, HTTP etc.). You can focus on these through book-learning, playing with diagnostic tools (e.g. host, ping, netcat, curl, traceroute, tcpdump), reading relevant RFC's and specifications or reading the code/documentation of common client/server software.
  • Web application security. The best way to learn about web application security is to implement attacks on your own. To that effect there are plenty of task-based training courses available online. There's Google Gruyere, OverTheWire and our own Rails Security Challenges. The most important book for learning web security is The Web Application Hacker's Handbook.
  • Cryptography. You will at some point or another have to make intelligent decisions about cryptography. There are vanishingly few ways to get it right. To get a high level-overview, I suggest you work through Cryptography Engineering. To really know how cryptography fails I thoroughly recommend working through the Matasano Crypto Challenges. By completing those challenges you'd place yourself in the very small group of developers that even remotely know what they're talking about when it comes to crypto (and bloody hell would it be awesome if we had a company full of developers like that!). Your most common interaction with crypto will be via TLS, so it's worth learning how it operates in detail.
  • Operating Systems. System calls, filesystems, memory, paging, threads, processes, scheduling and basic computer architecture underpin everything we do with computers. You need to understand how your operating system works before you can start to understand the trade-offs in the software we use (like nginx, git, PostgreSQL, Ruby, Redis etc). Your operating system is the context in which all of these things run. You'll need to build understanding of the underlying theory and ability with diagnostic tools that let you see your own OS at work. Learning a little C will help.
  • Basic data structures and algorithms. The central insight you get from learning data structures and algorithms is that there are different ways to achieve the same result with computers that have drastically different performance characteristics. Start with linear data structures like stacks, sets, queues, linked lists, arrays, hash tables etc. as they are the most conceptually simple ones. You can elegantly solve a much larger set of problems with tree-like data structures and graph algorithms. Finite state machines turn out to be immensely useful in a huge number of situations. Often the best way to learn about these algorithms/data structures is to implement them yourself in your programming language of choice.

This list is non-exhaustive. There are thousands of other topics that you could be spending your time on. If you got into programming (as a lot of developers do) thanks to a childhood wish of making your own video games then this is your opportunity to do so. If you're paranoid about your lack of maths ability then here's your chance to pick up a good textbook, put in the time and get better. If you're intrigued by functional programming and want to know what all the fuss is about then by all means go and teach yourself a lisp, Haskell, Erlang or whatever you like. The only rule: be fearless. If there's a topic you want to learn, you have the time and resources to learn it now, no matter how hard you think it is.

Spending your time productively

If you've built up your skills to the point where you're able to work productively as a developer then you are self-taught. You already have techniques for learning things. By no means is what I'm about to say prescriptive: you already know how to teach yourself things and you should follow your usual methods. Below I'm sharing a few techniques that have worked for me and are almost definitely a good use of your time. You're welcome to do them all or ignore them and learn the way you know best.

You're given one day a week for training, but I don't think it's going to be very useful for you to spend the entire day reading random articles on Hacker News or Reddit. There are going to be some activities that are more suited to making a meaningful impact on your skills and knowledge than others. The following are examples of activities that I believe will deliver the most impact for time spent:

  • Active reading of high-quality material. By high quality material I mean most things but the average blog post or stack overflow answer. Think books, specs, RFC's, academic papers, documentation or actual source code. By active reading I mean the opposite of how you read the average blog post. You'll probably need a text editor or notepad open to take notes and a terminal window to try out code. You might want to use something like the the SQ3R method if it's a topic that's a little more unfamiliar to you. Think deep immersion in a topic over a few hours rather than a ten-minute skim of an introductory article.
  • Small, easily-finishable training projects. Small projects with well-defined requirements are a good way to bootstrap your knowledge about more or less any given technical topic. For games programming you could build pong in your language/platform of choice. To learn network programming you could build a simple TCP echo server. If you want to learn computer vision then perhaps a simple script to detect faces in images might be a good first step. If you're teaching yourself robotics, a simple rover that moves in random directions is a fun little project to finish. The only trick is to keep the requirements small and well-defined. That way you can focus on implementing them well, then either iterate or quickly move onto your next training project.
  • Contributing to open-source software. Working on OSS means working on software that solves a problem for other developers. It forces you to think about how other developers will use your code. If you're working on an established project it forces you to work with other developers and understand alien code before you can make any sort of meaningful contribution. It weaves you into the developer community and provides public evidence of your technical skills. This ranges from starting your own libraries to becoming e.g. a Rails core contributor.
  • Writing technical articles. Putting what you've learned in writing makes it clear where you know what you're talking about and where you're still vague on the details. They force you to do research and fill the gaps in your knowledge so you can present a locally complete version of a subject to your audience. If other people actually read what you write, they'll quickly point out errors in your thinking and improve your understanding. You can keep your articles to yourself, share them with the rest of the company or make them publicly available.
  • Preparing for and delivering technical talks. Doing talks gives you many of the same advantages of writing technical articles. In addition they exercise your presentation skills and require you to remember a chunk of content on your subject matter. You're made to condense the key ideas of a topic into a twenty or thirty minute presentation, which is surprisingly much harder to do than e.g. a one-hour presentation where you have more time to build context. Delivering a talk is excellent for increasing your percieved expertise on a topic.

When in doubt, do what you've done so far to learn what you've learned. There's no test at the end of training day. No one will be monitoring your progress. It's there for you to learn whatever technical topic you want to learn in a way that works for you.

Wrap up

My aim with this article is to make it clear to you why we have training day and perhaps inspire you with some ideas of what to learn and how to go about doing so.

If there's anything here that you disagree with, need clarification on or would otherwise like to discuss then bug me over chat/email and we'll talk.

@yemster
Copy link

yemster commented May 26, 2015

Excellent write up Najaf. I may even borrow some parts of this.
I'm sure you won't mind :)

@iancox
Copy link

iancox commented May 3, 2017

This is great. Thank you

@iancox
Copy link

iancox commented May 3, 2017

Najaf, I'm considering a similar model at my digital agency. May I have 30 min of your time to talk about how you implemented the training day schedule given the business realities of running an agency?

Any help would be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment