Coding outside of work is a hot topic.

On one side is the Rise and Grind™ hustle culture, and on the other is a group of people that tell you to just go enjoy your life.

Read a book. Bake some sourdough. Learn carpentry. Anything—just not anything on a computer!

The truth, I think, is somewhere in the middle. Like any important topic in software development, the answer is often it depends.

Let's talk about coding outside of work. The career benefits, the burnout, and the ultimate life question behind it all: what do you actually want?

A career at light speed

I started my first development job in late 2012. I joined an existing company that seemed like it was run intelligently and had good future prospects.

This was before news and buzz around startup culture had permeated every corner of our lives—or at least mine.

I took a job doing .NET development along with some Classic ASP, VB 6, VB.NET, and C# ASP.NET.

Most of you reading this probably don't even know what half of those languages or frameworks are. This was before JavaScript development was front and center in the tech world—before most of the development world knew about React, Angular, or Vue.

At this job we used the most powerful JavaScript tool we had: jQuery. And for most of the apps we were building, jQuery was enough.

I was on was an internal applications team, and we built and maintained the internal CRM, customer support tooling, and database schemas that the sales, customer support, and product application developers relied on.

Looking at the job as a whole, it was a pretty good first job. The pay was decent, the people were intelligent, and I was overwhelmed with the amount of new topics and learning I had to do (which was a good thing).

I was on a relatively small team of five or so people, and I was learning frontend, backend, and database development at the same time—although I didn't really know what those terms were at that time.

There was one problem: I hated being there. This job was destroying my soul on a daily basis.

Part of it was the technology we used which felt archaic and dull. And part of it was the internal codebases we worked on (product design/user experience was intentionally ignored for the benefit of cramming the most information possible on the screen).

But the biggest factor was the company culture.

Still, I did have one saving grace: my time spent coding outside of work.

The Ruby on Rails logo

Enter Ruby on Rails

Around this time, by chance, I had met a new friend who was also a developer. Back then, he was the only developer friend that I knew. We started hanging out more and as a result we started to tinker on different projects.

Outside of work, on nights and weekends, he and I started learning this relatively new framework at the time known as Ruby on Rails.

I loved it. It was the incredible opposite of everything I hated at my job.

It was easy to use. The "convention over configuration" mantra that Rails was built upon made so much sense.

Instead of writing the same stored procedures over and over in SQL Server I could just call a one-line function in the Rails framework. Why re-invent the wheel when a lot of really smart people have already figured this stuff out for me?

At work I developed applications using Windows GUIs that looked like they were developed in the 90's and had never been updated.

After work I ran all of my Rails commands from the terminal and felt like the baddest hacker there ever was.

At home I could build anything I wanted. I could use this shocking new CSS framework called Bootstrap CSS. The world was my oyster. There were no rules—no one telling what I could or could not build or how I had to build it.

During this time my wife was in law school and she was studying almost constantly. While she studied late into the night, I built dumb toy applications. In the morning I would get up early to watch tutorials and practice building apps, and then I would go to my day job and endure the day of work there.

At home I felt the creative flow and power of creating something new. At work I felt trapped.

I continued this for quite a while—until one day I finally couldn't take it anymore.

Onwards and upwards

I had finally had enough. I talked with my wife and we decided it was time to look for a new job.

As luck would have it, I found a company in my city hiring Ruby on Rails developers. I was still incredibly new to Rails—and I had only been doing real software development for a little over a year—but they saw enough potential in me to hire me and were willing to train me in the things I didn't know (which was a lot).

At this new job (which was infinitely better), I continued to build and learn and practice at home. I knew from an early age that I wanted to own my own business, and I saw software as the path to get there. So I continued to learn, practice, and build on the side.

Failed startup. 3 Months funding. You in?

A short time later opportunity struck. A startup here in the city had failed, the company had disbanded, and the lead investor was wanting to give the product one last go.

The same friend that I had been building on the side with was connected with the investor through a mutual friend. My friend gave me the pitch: we've got three months of funding to see if we can turn this product around—after that who knows.

Imagine yourself in that scenario. Would you take it?

This job did pay much more than I was currently making—but only three months of funding? Who would quit their nice, stable job for something that possibly only existed for three months?

Well, I did.

There are many other lessons that I could write about that experience, but I want to focus on one thing: the application we were trying to resurrect was written in Ruby on Rails.

At this time I didn't know this, but I realize now what I had been doing all along: I was paying the cost of the opportunity. All of those nights and weekends I'd been coding away were practice and preparation to take on this opportunity.

Today, I can word that moment more succinctly: the cost of an opportunity must be paid before it arrives.

In this new job, I grew tremendously. At one point I leading a team of five developers, two designers, and helping the business meet the objectives set forth by our investor and CEO. It came like a whirlwind, and it consumed my life.

I was not only coding all the time and polishing my backend skills to a razor edge, but I was also planning, leading a team, and mentoring other developers. It was many years of experience crammed into an incredibly hectic year.

The aftermath

After a year, this resurrected company imploded in glorious fashion (long story classic startups blah blah blah) and I moved to consulting.

Although this particular company failed, this pattern of learn, practice, opportunity continued to happen throughout my life and career.

A short time later, I was introduced to a new framework called Phoenix built on top of a language called Elixir (which itself was built on top of an old language called Erlang).

The same thing happened again. I learned it, practiced it, and a year later a simple consulting gig morphed into taking on the role of "Contract CTO" of a small startup company.

Looking back it feels a little serendipitous, but each of those little decisions linked back to one thing: coding outside of work:

• Took on CTO role at startup
• Took on CTO role because I learned Phoenix outside of work
• Heard about Phoenix from friends met at previous startup
• Joined previous startup due to friends made before and skill with Ruby on Rails
• Grew my skill in Ruby on Rails from job
• Got Ruby on Rails job from building side projects in Rails
• Picked up Rails because I hated my life (kidding but also not)

Learn. Practice. Seize opportunity.

Coding outside of work is not a magical force. The magical part is the habit of continually learning, practicing, and building.

This simple little practice rocketed my career years ahead—from commuting in every single day to a job I hated to working remotely with control over my time and energy—building the life I want to live.

A classic.

record scratch—rewind.

At the beginning of this I said I was going to talk about the tradeoffs of working outside of work, but so far I've only talked about the amazing things that working outside of work brought me—and it has brought some really great things.

Well, this is the part of the movie where we rewatch the flashbacks with a different musical tone underneath. I just played you the highlight reel—but there's another side to this coin, and it's the cost of coding outside of work.

Health, relationships, career—pick any two?

Let's rollback to the startup company I joined that only had three months of funding. Was it an incredible growth opportunity and at times incredibly rewarding? Definitely. Was it also a sustained period of overwork, stress, wasted opportunity, and unhealthy self-soothing? Definitely as well.

You see, there's only a finite amount of time and energy a human can put into any activity. We only have a set amount of time per day. If too much time is allocated to a particular thing, that extra time is being stolen from another thing.

At my first startup when we worked insane hours day after day, night after night, and weekend after weekend—that time came from somewhere.

It came from time with our friends, families, finances, and from our health. We didn't sleep enough. We constantly ordered food from restaurants to sooth the stress and pressure we felt on a daily basis (food is a powerful soother, and it's often forgotten about since it's one of the more socially-acceptable vices to have).

No surprise here: our bodyweight went up and our health went down. Heavy meals, sugar, and caffeine fueled us.

Our relationships suffered as well. Time with our families was rare, and too much of the short time we had with them wasn't quality time—our minds were still at work.

I doubt this story is surprising to you—it's a classic tale. Person gets absorbed in work and throws away their family and their health. It's cliché, but it's true.

We'd think we needed to grind for "just another two weeks / just until we finish this piece of the product for this upcoming event / just until this meeting with the investors/potential acquirers."

Once before an Important Demo™ we stayed at the office and worked through the entire night—including sleeping on the ground for a quick nap before the demo.

But that time would come and pass, and then the next milestone would show up—and the cycle continued again.

Burned out, and for how long?

While there were some incredibly fun moments along the journey, the burnout and fatigue continued to mount. That's the cost of working too much outside of work: eventual burnout. We only have so much to give before we have to recharge.

And that burnout takes a long time to recover from.

There's an old adage about relationships that it takes half the length of the relationship to move on, and that's how it felt for recovering from burnout.

Even to this day I feel the dullness of burnout hiding just outside of my periphery. It's always there, ready to creep back in.

The one important question

Let's replay those flashbacks one last time.

These are the honest truths of the benefits and detriments of too much work outside of work. But the thing is, the truth is really somewhere in the middle, and I think the answer is determined by this question: what do you want from life?

It's a terrible question—not because it's a bad question, but because of how heavy and difficult it is to answer it.

What do you want? What do you want from your life?

The question is not should you code outside of work or not—but what do you want to gain from it, and what are you willing to pay for it?

There's no doubt that working outside of work has launched my career forward years at a time. There's also no doubt that it had a cost. When people I knew were taking vacations, watching Game of Thrones, or just plain enjoying their lives—I was working.

Do I regret all of that time working? Definitely not. I've gained a large amount from it. Do I regret some of it? Yeah definitely.

The important thing is to define what you want, and what you're willing to pay for it.

Depending on who you are and where you are in your life your answer will be different, and that answer will likely even change over time—it has for me.

A young, single person just starting out in their career may decide to pay now to reap the rewards for later.

A person coming to development with an existing family and responsibilities may be content with just working their 9-5 job and shutting it off for the day. That could be all they want—a stable and full life with their family.

There's no right or wrong answer here. There's just your answer. Each decision has consequences. Define what you want, what it takes to get there, and what you're willing to do for it.

I have a daughter now, and when she was born I decided to prioritize my time with her. If a similar opportunity arrived now that would require grinding away my nights and weekends, I wouldn't take it. I have things that are now more important than that (and for the record, I now also don't think that it requires that).

10,000 hours?

In what is now regarded as a somewhat controversial book, Malcolm Gladwell's Outliers: The Story of Success often mentions this concept of "10,000 hours":

Throughout the publication, Gladwell repeatedly mentions the "10,000-Hour Rule", claiming that the key to achieving world-class expertise in any skill, is, to a large extent, a matter of practicing the correct way, for a total of around 10,000 hours, though the authors of the original study this was based on have disputed Gladwell's usage.

Regardless of if the "10,000 hour rule" is correct or not, there is no doubt that someone who practices more at a particular thing will have a better result than someone who practices less. Or at least that person will reach their desired result faster than the other person (given the practice quality is the same, which is a big "if").

It's because of this that I understand those who champion work outside of work.

On the other hand, it's been well-studied that there are significant diminishing returns on working long hours.

TL;DR: Google says not to overwork.

In fact, a 2014 study from Stanford University and the IZA Institute of Labor Economics showed that work done after a certain threshold (~55 hours per week) doesn't give any noticeable benefit. I've found this true in my own experience as well.

In my experience, consistent weeks over 40 hours of work led to a loss of strategic thinking, numerous mistakes, and a litany of burnout effects.

I was recently pointed to an episode of the Indie Hacker's podcast where the creator of the Ruby on Rails framework, David Heinemeier Hansson (or DHH as he's been come to be known), was discussing this very topic with another successful software entrepreneur, Natalie Nagele.

DHH is known for his bold (and sometimes harsh) stance of not working outside of work. He points to his success with his company Basecamp, and the fact that they barely ever worked more than 40 hours per week.

While there's obviously more to the story than what he can share in one podcast episode, there's one point that he stressed on that I think is crucial: the quality of work matters.

At first, some quantity—then all quality.

You need some quantity of work to get going, but once you get moving, the quality of your work becomes much more important than the quantity of work.

Don't underestimate the growth from one focused hour of learning each day. Two hours isn't necessarily better—nor is four.

Like I talked about in my post How To Become an Outstanding New Developer, aim to be 1% better every day. A 1% improvement every day is a 37X improvement over a year.

Small and consistent wins will always beat out a short burst of intensity.

Neither good nor bad

So there's the actual truth behind coding outside of work. It's neither good nor bad: it's a choice.

It's a choice with different consequences. Neither outcome is bad if that's what you decide you want.

There's no doubt that more time, energy, and practice on a craft will make you better at it—saying anything otherwise would be silly. But, there's also no doubt that there is a cost to pay from the other areas of your life.

I now don't think working all the time outside of work is required—let alone beneficial. There's a sweet spot between some focused, intentional effort and enjoying the life you're working so hard to build.

DHH once tweeted something that has been seared into my brain:

Since I read that, I've been trying to figure out how to "waste some time" on the rest of the human experience. At some point, I think we all have to do that.

So the question that it all comes back to is this: what do you want?

If you've enjoyed reading this, I write similar things on my blog.

Thanks for reading!

John

The best learn-to-code projects are often those which solve a real world problem.

These projects can provide that extra dose of motivation so essential to finishing any project. They encourage you to actively explore and discover new concepts, rather than imitate examples you've seen before.

There's also something that bit extra satisfying about solving a problem you face day-to-day.

An easy way to start is with Google Apps Script.

It is a scripting language for a range of Google applications. The language itself is in fact JavaScript.

What Google Apps Script provides are libraries and classes that allow you to work with objects such as spreadsheets, emails, calendars, slides, and more.

If you want to dive right in, the documentation is available here.

Here are three examples that will show how to get started with Google Apps Script. Hopefully it will give you some ideas for your own projects!

Launching Google Apps Script

You will need a Google account to start developing Apps Script projects. To start a new project, simply navigate to script.google.com/home and click 'New Script'.

You will be taken to an in-browser IDE that looks something like this:

Give your project a name by changing the title in the top left corner.

Note that every time you require Apps Script to access different Google applications, you will need to give the necessary permissions.

This might look a bit daunting, but if you are running your own project carefully, there will be no problem. Click "Advanced" and allow your project permission to run.

Let's take a look at some examples.

Calculate your income tax

This simple example will show you how to extend Google Sheets by adding your own custom formulae. In this example, the formula will be used to calculate UK income tax.

In the UK, different income tax rates are applied to different earnings categories. Therefore, the amount of income tax owed varies depending on the income.

First, create a new Google Sheet. Then, from the menu ribbon, select Tools > Script editor. You will be taken to the Apps Script IDE.

The code block below uses a switch statement to calculate the right amount of tax for a numerical argument income. If you are familiar with JavaScript, you will recognise the syntax.

function TAX(income) {

  switch (true) {

    case income <= 12500:
      var tax = 0;
      break;
    case income <= 50000:
      var tax = 0.2 * (income - 12500);
      break;
    case income <= 150000:
      var tax = 7500 + (0.4 * (income - 50000));
      break;
    case income > 150000:
      var tax = 47500 + (0.45 * (income - 150000));
      break;
    default:
      var tax = "ERROR";
  }

  return tax;

}

Save your project if you haven't already.

Now, back in the sheet, enter your chosen salary in e.g., cell A1. You can now call the new formula with =TAX(A1).

You could write a similar function to calculate UK National Insurance contributions.

What other Sheets functions could you write?

Remember to check your emails

It can be difficult to make time to respond to important emails. This example will bring together Gmail and Google Calendar in one short application.

The idea is simple. You provide a list of important email contacts and/or keywords. The application checks your inbox every six hours. If it finds any new emails from these contacts (with any of the keywords in the subject line), it creates a calendar event reminding you to reply later in the day.

You can create a new project from script.google.com/home.

Check out the code below:

function reminder() {
  /* create list of senders and subject keywords */
  senders = ["freecodecamp", "codecademy", "meetup"];
  subjects = ["javascript", "python", "data science"];

  /* build the search query */
  var searchString = "is:unread newer_than:1d from: { " +
    senders.join(" ") + "} subject: { " + 
    subjects.join(" ") + " }"

  /* retrieve any matching messages */
  threads = GmailApp.search(searchString);

  /* if there are any results, create a calendar event */
  if (threads.length > 0) {
    var event = CalendarApp.getDefaultCalendar();
    event.createEventFromDescription('Review emails 6pm today');
  }

}

To run this function at regular intervals, you can set up a trigger. From the menu ribbon, choose Edit > Current project's triggers.

This will take you to a new tab where you can add a new trigger for the current project. Click 'Add new trigger' and choose the settings you wish to use.

Now, your script will run every 6 hours, and create a calendar event if you have any emails you need to review.

A useful extension might be to create a spreadsheet or Google Form that lets you add contacts and keywords easily.

How else could you integrate your inbox and your calendar?

Slides update

Keeping presentations and slide decks up-to-date can be a tedious task. Luckily, you can use Google Apps Script to automate the process.

For this example, we'll use a fictional mobile app. The aim is to produce a slide deck with up-to-date metrics such as app downloads, active users, and revenue.

The trick will be to replace a number of <tags> in the deck with data contained in a Google Sheet.

In Slides, create a new presentation. Give it a name such as "App update template".

Create a new slide. Give it a title such as "Key metrics".

In a text box, add some content such as below:

Notice the tags included in each line. These will be replaced by up-to-date figures each time the script is run.

Next, create a new Sheet and add some data to use in the slide deck. In one column, refer to the tags in the slide deck. In the other, add the latest data.

In a real-life example, this would be calculated from raw data elsewhere in the spreadsheet. The raw data could come from Google Analytics, or be exported from a data warehouse, or from some other source.

Back in Slides, select Tools > Script Editor from the menu ribbon. This will open a new Apps Script project.

Now you can start writing some code. The function takes two file ids as arguments - one for the Slides template, one for the Sheet. The file id is the string of letters and numbers you can find in the file's URL.

function updateSlides(templateId, sheetId) {

  /* Make a latest copy of the slide deck template */
  var template = DriveApp.getFileById(templateId);
  var today = Date();
  var copyName = "App update " + today;
  var templateCopy = template.makeCopy(copyName);

  /* Open spreadsheet and slides by their id*/
  var sheet = SpreadsheetApp.openById(sheetId);
  var slides = SlidesApp.openById(templateCopy.getId());

  /* Get the data from the sheet */
  var data = sheet.getRange("A1:B5").getValues();

  /* replace all the tags in the deck with their latest values */
  for(var i=0; i <data.length; i++){
    var tag = "<"+data[i][0]+">";
    var value = data[i][1].toString();

    slides.replaceAllText(tag, value);

  }
}

If you run this script, a new presentation will be created with the latest data in place of each of the tags.

You could schedule this script to run at regular intervals, such as at the end of each month. If you wanted to develop the idea even further, you could use Apps Script to automatically email the new deck to a list of contacts.

Over to you

Google Apps Script is a great way to start writing real JavaScript in a way which is immediately practical. Hopefully you found these three examples helpful.

Perhaps this introduction has given you ideas for projects you could develop?

Remember, coding is a powerful tool - don't do anything with Apps Script you wouldn't do manually. Best not to erase your entire inbox or overwrite an important file with memes.

Thanks for reading!

I’ve had a topic on my mind over the previous days that I can’t shake off. So I knew I had to write an article about it.

The idea is simple: for most of the external constraints on my studies and career, I chose to see the bright side and make the most of them, turning them into opportunities. It’s easy to feel stuck and spend our days complaining about our unlucky state. But it’s almost always possible to turn our seemingly sour lemons into tasty lemon cakes.

The best way for me to show you what I mean is to share four examples from my life, in chronological order.

1. Lack of time led to an increase in focus and productivity

I got married during the summer of my fourth year of university, where I was studying computer science. My wife was a med school student and was working long and hard hours. For our wedding, we wanted to invite the people who mattered most to us and throw a big and memorable party.

Since my wife was too busy, we decided I would organize all the practical aspects of the wedding. For those of you who’ve gone through this, you know this can get pretty heavy. Wedding planning started to take most of my free time, so much so that I struggled to find time to study and work on projects for my degree.

This forced me to take a hard look at what was essential in my studies, what was superfluous, and what could be optimized. I decided to skip most classes where I felt that the teachers didn’t add substantial value over simply studying the manual. And I started to focus on only the essential takeaways for a given project. My goal was not to be valedictorian. It was simply to pass without worry.

This is when I discovered the Pareto principle, also called the 80/20 law. It states that in most areas, 20% of the causes leads to 80% of the outcomes. So once my goals were clearly stated, I started to focus on the minimum that needed to be done to attain my goals.

Feeling time pressure forced me to focus and learn many productivity hacks, which have followed me through the years.

Oh, and by the way, the wedding was a blast and I passed the year without much hassle. I even got better grades than a few friends who had way more time than I had but who were not forced to focus.

Please tell me you’re scared ?

2. Lack of mobility led me to join an outstanding company

Upon graduation, I joined the IT services company Atos as a software consultant. As with most services companies, they could send me to work at their client’s locations. These could be anywhere in the region, with commute time going as far as two hours one-way.

I started working on a few crappy Java projects for large government-owned companies where nobody cared about the projects. And nobody around me at Atos seemed to care about writing good software. You know, as long as the apathetic client pays…

I felt stuck. All my graduation enthusiasm started to fade away. Was this what writing software was all about? What if I studied to become a baker instead, at least people would care about my bread…?

Hmmm the smell of good software ?

And then baby #1 arrived. Since my wife was still in her medical studies program working long hours, it meant that I would be the one preparing our girl in the morning for day-care. I would also be the one picking her up in the evening to then getting everything ready before mummy came home. But with potential two hour commute times, this would be impossible!

This forced me to look for other opportunities, at companies that didn’t send their employees two hours away with little notice. And this led me to find a great job at a company called ESKER, which is an outstanding employer (literally outstanding, boy was I lucky!).

I would not have looked for a better job had I not been forced to by external circumstances. And this has been one of the best decisions in my career so far.

3. Lack of ability to work full-time led me to become a developer

When baby #2 arrived, with my wife starting her medical residency/internship (where she would work even crazier hours!), we realized that we would not be able to both work full-time.

So I decided to work part-time to be able to handle most of the family logistics. At the time, I was working in a management role but was missing writing code. Still, I felt like I didn’t have the time to study in order to prepare for a career transition.

The great thing is that a few months into my switch to part-time, I became increasingly efficient at handling the day-to-day affairs. I started to find a few hours each week to get back into code. That’s when I realized that I loved it and that I wanted to go back to software development.

I decided to dedicate 10h a week to learn web development with freeCodeCamp (I mostly worked with Java, C/C++ and Python before that, but never really touched anything web-related). A few months later, I passed the tests to become a software developer at my company.

/me wannabe hacker when the kids are asleep ?

Becoming a developer has been the most fulfilling career move I’ve made so far. I can truly say that I love this job and the possibilities it offers.

And this would not have been possible without the family constraints that forced me in the first place to go part-time!

4. Lack of ability to work on-site led me to become a remote freelancer

Then baby #3 arrived, and my wife still a medical resident/intern. Since my eldest daughter needed to be taken care of during lunch breaks, it became increasingly difficult for me to work in an office with traditional work hours (like 9 AM to 6 PM).

I didn’t think it was possible for me to find a remote gig with flexible hours with my current level at the time. So I told my company that I would take a parental leave for two years until my wife finished her residency/internship.

And then the magic happened: they asked me to consider creating my own company so I would be able to work for them from home as a contractor. I could then just bill only the days I worked.

Of course, this is my daily work environment. Tell me you’re not jealous ?.

I accepted, and this has again been one of the best decisions in my career. I now work between 15h and 25h per week, depending on my client’s needs and my availability. During school vacations, I don’t have to ask for vacations. I simply tell them I won’t be available as a contractor. And I’m enjoying lunch with my daughter every day.

TL;DR

I’m delighted to be able to work as a freelance, remote employee with flexible hours, doing things I truly enjoy and find fulfilling (like writing JavaScript to meet real-world business needs. I truly mean it).

But this would not have been possible if I hadn’t learned to be productive and focused as a student, so I could work without distraction from home and without supervision.

And it would not have been possible if I hadn’t joined this outstanding company with such outside the box thinking.

And it would not have been possible if I hadn’t been able to learn web development with the time I found while working part time.

And it would not have been possible if I hadn’t decided to take a parental leave to take care of my kids…

You get the point. The biggest opportunities in my career have come when I was trying to make the most of external constraints without fighting against them or complaining about them.

So the next time you feel constrained by your life and career, don’t curse the sour lemons. Look directly at them and tell them straight: I’m going to turn you into the best lemon cake in history!

PS. If you don’t like lemon cake, try lemonade instead ?

Originally published at www.samuelpath.com on February 9, 2018.

Please do not hesitate to share your thoughts on Twitter, I’m at: @smlpth

The impact of a company’s culture is reflected in a company’s ability to achieve their goals and productivity levels, and in their employees’ satisfaction. The company culture can make or break a business.

Yet, company culture is the one thing that many aspiring programmers overlook in their job search. Unfortunately, they usually find out after accepting a job offer that they are working for a company with a very poor culture. That oversight can have a negative impact on their career.

To better explain the impact of company culture, I am going to use experiences from my career to illustrate.

Working hours

The 9 a.m. to 5 p.m., 40-hour work week is a reflection of how work was performed in the Industrial Revolution. During this time, workers punched a clock which measured the amount of time worked. Management used the punch clock to gauge employee productivity.

Today’s software engineers are smart, creative people who prefer to work in an autonomous environment to create their best work. Unfortunately, at some companies, management still clings to hours worked as a barometer of productivity.

The following examples are how two management teams from two different companies that I worked for view work hours.

First company

This company provided flexibility to employees in terms of when they started and ended their work day. The only requirement was that every member of the team had to be available during the same six-hour window during the day.

This provided flexibility to employees so that they could schedule doctor visits, receive home deliveries, tend to their homes and car repairs, and so on.

Second company

Management sent an email to every programmer, asking them to declare their time of arrival at and their time of departure from work every day. Later, we received another email explaining that people were not adhering to when they said they were arriving at and leaving from work. Shortly thereafter, upper management was sitting at the front of the office when people arrived at work. They were probably noting when their employees were arriving at work.

Normally I arrived at work around 8:00 a.m. One morning I arrived at work at 8:30 a.m. Upper management commented that I was late for work. There were about 20 people that worked in the same office, and I was the second programmer to arrive at work that day.

_Photo by [Unsplash](https://unsplash.com/photos/GxnyOLTxCr8?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Jonathan Simcoe on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

How to avoid it

Avoid companies that measure your success by when you arrive at and leave from the office. Instead, work for companies that measure your success by the goals you meet. When interviewing with companies, ask if they have core work hours or standardized hours.

Companies with core work hours require that every member of their team be available during those hours. Employees can set their start and departure time based on these core hours. For example, if core work hours are 10 a.m. — 4 p.m., employees can start work at 8:00 a.m. and leave at 4:00 p.m. Or, employees can start work at 10:00 a.m. and leave at 6:00 p.m.

Encourage or discourage employees taking action?

Following the Pareto Principle, the overwhelming majority of employees will treat work as something they do between 9:00 a.m. and 5:00 p.m. These employees will not make an effort to learn new skills or technology on their own. The remaining 20% of employees will invest their time and energy on learning and improving their knowledge. Companies can decide to either foster employee development or to neglect it.

The following are examples from my work experience of how management treated employees who spoke at conferences.

First company

I was selected to speak at my first technology conference. The conference was Connect.Tech, which is the premier web and mobile development conference in the Southeastern United States.

Within 48 hours of it being announced that I would be speaking at the conference, our director purchased conference tickets for every developer in the department. My director wanted to support me because I had invested my time and effort to master a skill that I would be speaking about at the conference.

Later, after accepting to speak at my second technology conference, the director pointed out that I was speaking again and gave me a monetary reward for my efforts.

Second company

This company was in the process of rewriting their website from PHP to AngularJS. I was selected to speak at ngConf, which is the world’s largest conference on AngularJS.

To speak at this four-day conference, the company required that I take two days of vacation. I was also given two days off. The conference covered my airfare and hotel, but I paid for my own food and taxi rides.

At the last minute, another programmer decided to attend the conference. The company paid for his airfare, conference ticket, hotel, taxi rides, and food. As well, the company gave this guy four days off to attend the conference.

Later, I asked the company if they would also cover my food. They responded by saying that I was being self-centered and just wanted to exploit the company’s resources.

How to avoid it

As you can tell, the company culture in these two companies are drastically different. When you look for a job as a software engineer, make sure you do your research about the company first. Try to figure out whether or not the company invests in their employees’ development. Does the company encourage their employees to improve their skills? Or does the company discourage it?

Work processes and quality control

Quality assurance (QA) is a part of the software development life cycle. QA ensures that there are no bugs in the code. The longer a bug goes undetected, the more costly it is going to be to fix it later on.

Git is the primary tool programmers use for version control. Programmers in a team must have a strategy to control the codes used in production-ready codes.

The following are examples from my work experience. They show when companies invest in their work processes and when they do not.

First company

Every programming team had a QA person. QA was responsible for checking the programmers’ code and verifying that it met the acceptance criteria for the story. If the QA engineer had concerns with the quality of the code, it was the programmer’s responsibility to re-do the code until standards were met.

The programmers used a Version Control System workflow (VCS) to create branches that reflected the number assigned to the story. Once programmers completed their code, they were required to merge the master branch into their code to see if there were any merge conflicts. Once that was done, they submitted their code to the master branch.

Before the end of the sprint, the entire team would spend a day verifying that the code on the master branch met the acceptance criteria for every story. Programmers were required to verify the work completed by others, but were not allowed to test their own code.

Second company

This company did not have a single QA person on staff. They also did not implement a Git workflow strategy. As a result, programmers were responsible for testing their own code in relation to the story, but not in relation to the potential impact it might have on someone else’s code.

A release was pushed to production. The push resulted in the website going down. Luckily, the code was rolled back within seven minutes. In the following week, a team lead and several programmers tried to find a solution for the website outage. For several nights that week, they worked until 10:30 p.m. trying to fix the problem.

After resolving the problem, management sent an email praising the team leader for the hours he spent solving the problem. The email concluded that all employees should be willing to work the same number of hours to complete their work.

Instead of addressing the root problem, which was having an ineffective VCS strategy and a lack of QA resources, management decided to praise someone for the side effect.

How to avoid it

When interviewing with a company, you will probably speak to more than one developer on the team. Ask them if the company utilizes an effective VCS strategy. If so, ask them to explain what it is. It is important to know if all programmers provide a consistent answer to this question.

Another question to ask is what is the time between when an error with a production code is reported and when that error is fixed.

_Photo by [Unsplash](https://unsplash.com/photos/xcI7f25UQSs?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">Lauren Mancke on <a href="https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Work-life balance and vacation time

The Business Dictionary defines “work-life balance” as “a comfortable state of equilibrium achieved between an employee’s primary priorities of their employment position and their private lifestyle.”

Programmers should seek a job that does not demand an excessive amount of their time and energy that they miss their children’s birthday or taking their vacation.

The following are examples from my work experience of how management manage their employees’ work-life balance and vacation.

First company

This company provided three weeks of vacation. Employees could take vacation with as little as one day’s notice. There was no problem when one or more employee went on vacation at the same time.

If employees did not take their allotted vacation, it did not roll over to the next year. Between Thanksgiving and Christmas, the company sometimes worked with partial development teams. This is because programmers were sent home to make sure that they used all of their vacation.

Second company

An employee, along with four other couples, scheduled a trip to Hawaii where they had rented a compound on the beach for a week. Shortly before this employee was scheduled to leave for vacation, he was asked to reschedule his vacation. The reason given was that the company had an upcoming deadline, and they were behind on completing it.

When I tried taking time off, my team leader asked me to make sure that our deadlines would not be negatively impacted by my vacation. In other words, the company expected me to schedule my vacation around my work deadlines.

How to avoid it

Ask what benefits the company provides in terms of vacation and holiday. It is important to know if you are able to take time off without giving notice several days or weeks in advance.

During your interview, ask every programmer if they took all of the vacation time they were given, for every year they have worked at the company.

Conclusion

Company culture is a reflection of the leadership and work environment within a company. As a new programmer, working for a company with a positive company culture can catapult your career. If you end up in a company with a negative company culture, it can impact your ability to learn and grow as a software developer.

More articles

Thank you for reading my article. If you like it, please click on the clap icon below so that others will find this article.

Here are more of my articles that you might find interesting:

• 7 Things I learned in my journey from coding bootcamp to Senior Developer
• Instantiation Patterns in JavaScript
• The Secret to Becoming a Better Programmer is Speaking
• First Impressions Count — Why Doesn’t Your Github Repo Have a ReadMe File?

Shabbat is the seventh day of the week. It starts on Friday night and ends on the following evening, Saturday. (A day starts in the evening for the Jews.) It’s also the Jewish day of rest — the Sabbath.

Many Jews observe Shabbat because it is a commandment from the word of God. I practice it out of habit, and also because my friends and the Jewish community observe it. As well, I enjoy it.

Shabbat is a day where Jews do not work. For the Orthodox Jews, they also do not use electricity or drive on Shabbat. The day consists of prayer services, sit-down meals with family and friends, and for many, a good sleep.

For me it’s a day I appreciate because I am not allowed to check my emails or to scroll endlessly through my Twitter, Facebook, or Medium account. Also, I get zero notifications from my phone. It’s a time to shut all that off. It’s a day where I play games, read books, go to the beach, see family, and talk to friends.

I run an early stage start-up with some seed (and pre-seed) funding. My job can be quite stressful. A big part of me wants to code on Saturdays, but I’ve decided I won’t. I’ve never written a line of code on Shabbat, and don’t intend to in the foreseeable future.

I’m writing this post because of the Twitter discussion that took place.

Blake Robbins started the discussion with these tweets:

These tweets received some strong reactions.

These messages received many likes and retweets, but many people argued against it as well. I put myself in the “against camp.” I agree, burning out isn’t cool. You have to look after yourself. But having said that, I do believe that if you work harder than your competitors, you’re more likely to succeed than your competitors. However, hard work doesn’t guarantee success. But lack of hard work also doesn’t guarantee failure. Nothing is guaranteed. Hard work just increases your odds of succeeding.

I believe that if you want to achieve greatness, hard work is the only way to achieve it.

There were two notable figures involved in this discussion, DHH and Keith Rabois.

DHH is the creator of Ruby on Rails, founder of Basecamp, a Le Mans racer, and the commissioner of the one-of-a-kind Pagani Zonda HH.

DHH cannot be faulted for his taste in cars.

Keith Rabois is part of the PayPal Mafia and is an “entrepreneur, investor, contrarian,” according to his Twitter profile. And according to Wikipedia, he’s known for Paypal, LinkedIn, Square, Yelp, Xoom, YouTube, Yammer, Palantir, Lyft, Airbnb, Eventbrite, and Quora.

Two incredible and successful people.

These two have very different views on work and rest. They had a heated argument on Twitter over this topic. Not sure who’s right or wrong.

Rabois made a strong argument for hard work:

As mentioned earlier, Rabois is part of the PayPal Mafia, which includes Elon Musk and Peter Theil, among others.

Musk seems to share a similar view on work ethic:

Work one hundred-hour workweeks, and you’ll achieve in four months what it takes others a year to achieve.

Here are some tweets that supported Rabois:

If you read through the feed, you’ll probably find 100 more arguments that support working hard, from accomplished people.

On the other side of the debate is DHH and his camp. And DHH worked hard to achieve what he has too.

Burning out is bad. You’ll achieve a lot more if you work 40 hours a week for 5 years than work 100 hours a week for only one year. You’ll probably burn out and never enjoy or have the desire to work again if you do the latter. Okay, that was a bit exaggerated. But I hope that my point is clear: you need to look after yourself. That much is obvious. You don’t sprint a marathon.

There are other things that are important in life. For example, family, friends, community service, relaxation, and whatever else it is that gives you purpose. I don’t know what Rabois or DHH’s personal lives are like, but you can still have those things while you work hard. For example, Musk is married with kids. He found time to be away from work, which included Tesla and SpaceX, to have a family.

It’s important to respect people’s decisions. If people want to work hard to achieve something truly great, then let them. But if their priority is to spend time with family or to build a home, then let them. And if they want to do both, then let them do that as well.

I started this post by talking about Shabbat. I’m going to end it with talking about exceptionally hardworking rabbis, whose work is to study Judaic law, the Talmud, and the Bible.

These rabbis practically devote their every waking hour to their studies. I have seen eighty-year-old rabbis walking through the streets with a Talmud in their hands, studying. This is what they commonly do. They travel like this from place to place so that they don’t waste time.

Rav Nevbenzahl — never stops smiling

When I studied in a yeshiva (a Jewish institution that focuses on the study of traditional religious texts), I sat next to the man who is pictured above, Rav Nevbenzahl. He is a very happy man. He has a family and grandchildren. His studies give his life meaning. It doesn’t even occur to him to take a break.

What is incredible is that he’s been doing this for seventy years. He taught for many of those years and continues to teach. He prays three times a day, and used to sleep only two hours a night. (Although I’ve heard that he regrets it now, and you can catch him napping during the day now.)

He has completed the Talmud multiple times over. I don’t remember how many times, but I am certain that it’s well over a 100 times. Now that’s really impressive. Meanwhile, 99% of Orthodox Jews haven’t even finished it once, because it’s so long and challenging.

This is how someone who believes a man’s ultimate purpose is to study religious texts lives. He believes that by learning and teaching these texts, he’s helping to make the world a better place. And that each time he reads these texts, he too becomes a better person.

So I want to make it clear that I do not agree with this lifestyle. I do not share his belief system. I think it’s based on false premises and is outdated.

But this man is extremely happy, and is a caring and humble individual with a good sense of humour. He lives an extraordinary life that is entirely devoted to studying ancient texts, and it gives his life meaning and brings him incredible joy.

That is this man’s work. He never takes a holiday. Or a break. And he doesn’t need it. Some people don’t want it or need it. Some people prefer to work than sit on the beach for a week. However, you shouldn’t tell people how to live their lives just because you don’t want to work 24/7.

Myself, I love what I do and it never feels like work. I can code until midnight or 3 am, and sometimes even 8 am. And I love it. I also wake up at ridiculous hours, sleep 8 to 10 hours most nights, and show up at work between 11 am and 2 pm. And of course, I take Saturdays off. A good time to catch up on reading.