Coffee shop coders long for the old, distraction free times.

Sioux Falls, South Dakota— Coders all over the city long for the times when they would sit in peace, sipping their coffee, next to their MacBook Pros.

"It's just not the same as the old times when I could sit here undisturbed, able to get work done. Those were the good times. Now I have to deal with things like this family over here discussing how their day is going, or this guy coughing a lot while reading today's paper. It's all distracting me from getting my NodeJS app finished up and tested." said one coder, who wished to remain anonymous. "Don't even get me started on the people who come in and ask for the most inane drinks imaginable." she quipped.

Aaron, a freelancer who spends most of his working days in select shops around town, has noted similar issues.

"When I get started with my day, I am usually the only one here with a computer in front of them. Before long, everyone around is sporting a computer, using up all the bandwidth. That bandwidth used to be all available to just me, and it's disheartening. Spotify streaming quality suffers because of all the extra traffic. Because of this, my focus gets ruined and I fear my client site designs lose quality as a result."

One report states that Aaron received cold shoulders and looks of disbelief when he brought his concerns up to the baristas. Once he asked to speak to a manager, the manager told him that they can't just kick everyone else out. They said that the continual flow of customers is part of the daily revenue. These customers spend more money than Aaron does on his own.

When asked, both of our coders agreed that times past were much nicer. "It's just better for both of us before the lunch rush kicks in and no one else is around." Aaron then added "We'll just have to return early tomorrow and enjoy the salad days while we can."

No word yet on if they would try to work together to create their own peace.

Surviving Burnout

You wake up in the morning and you're late again, more exhausted than you were before you went to bed. This whole new day is looming over you, demanding you give a little bit more even though you have nothing left to give. What little sleep you managed to get was interrupted by an untouchable dread; you're not doing enough, you can never do enough.

You can't remember the last time you had a good day and it's starting to feel like you'll never have one again. Worse, you're not even sure if you care anymore.

When I reached that point, I was still a few months away from quitting my job and walking away from my career. I had missed the early signs of burnout and I was already starting down a dangerous path.

I can only credit my tenure with that company, ten years at that point, as the reason I managed to keep my job as long as I did. When I could even force myself to show up at work I was hours late. I did little work, and only a tiny fraction of that was of any quality. I spent shocking amounts of time in the toilet, sometimes weeping, sometime sound asleep. I was a complete and total wreck.

When I found myself daydreaming about crashing through a guardrail on my way to work one morning, I realized something had to change. This job, I thought, was killing me. I had to save myself, so I quit, and I spent the next few years draining my savings account. It was an incredibly destructive period in my life, but I did manage to do one very positive thing: I saw a therapist. It was through therapy that I started to understand what had happened to me and how I had gone from being productive and happy to being so miserable I could barely force myself out of bed. I learned about burnout.

Recognizing Burnout

In the simplest terms, burnout is exhaustion. It can be physical or mental, but it's almost always the product of long-term exposure to heavy stress, or situations that are physically or emotionally taxing. Burnout is where we get to when we've pushed ourselves to the limit and then kept pushing. It's when a two-week crunch turns in to six months of twelve-hour days and six-day weeks. It's what happens when we stop resting behaving like we're in a life-or-death struggle for survival instead of just working a job.

There are three primary symptoms that are associated with burnout:

  1. Exhaustion - Persistent tiredness accompanied by an inability to perform up to your ability. Chronic fatigue, insomnia, increased tendency to get sick, and forgetfulness are common signs of physical and mental exhaustion.
  2. Cynicism and Detachment - Lack of patience with others, lost interest in or feelings of hopelessness about your work. It's common to feel pessimistic about life and work and to isolate yourself from others.
  3. Ineffectiveness - Feeling that you can't accomplish anything and have no ability to change for the better. Burnout can make you irritable and apathetic and sap your ability to be productive.

Getting Help

I nearly lost my career to burnout because I didn't recognize it until it was too late. The company I worked for offered an excellent employee assistance program that could have set me up with a mental health professional trained in dealing with occupational burnout. Your employer may very well offer a similar benefit.

If you don't have coverage through your work, you can reach out to other mental health providers. In the US, you can usually find help through the American Psychological Association.

If it's just too much and you're even a little worried that you might hurt yourself, call the National Suicide Prevention Lifeline in the US at 1 (800) 273-8255 or your local crisis center.

Coming Back

I eventually returned to software engineering, very reluctantly. I needed money and health care and this is the only skill I have that lets me earn those things for myself and my family.

This time, though, I made a few changes to protect myself.

Get Involved - I make sure not to isolate myself. The first thing I did when I rejoined the industry was force myself to start attending meetups. Friends who understand your work are an incredibly powerful tool to prevent burnout and help you keep your perspective. It can be so hard to open yourself up to strangers but if you can manage it, it's amazing how fast strangers can become friends.

Make Health a Priority - Make the time to care for yourself. Eat well, get enough rest, and do the things that make your mind and body happy. Make these things a priority in your life. A healthy you comes first.

Set Boundaries - Even when all the deadlines are crashing in, take time away from the computer and disconnect. Learn to say "no" and guard your personal time carefully--you can't get it back!

Learn to Manage Stress - Find something that works for you and make it part of your routine. Go for runs, pick up table tennis, or learn to thrash on a guitar. Stay connected to the important people in your life. Their support will help you more than you can imagine.


Burnout starts slowly and by the time you realize something's wrong, it can already be too late. Learning to recognize the warning signs can help, but it's just as important to build a strong support network that you can rely on. They can help you manage the stress that leads to burnout and help you realize when it's time for a break.

Like many of life's struggles, burnout can lead to a new beginning. Just remember that even when it seems hopeless, or like nothing can ever get better, you can survive and you can thrive again.

There's always a first time: the story of my first Pull Request

It was just another day at the office: got my coffee, opened my PHP IDE, joined some IRC channels in case I needed help with something code-related. It was my first year in Amsterdam, my first year getting involved with the PHP community. By that time, I never had been in a PHP conference before, and the only "PHPeople" I knew in real life were from the AmsterdamPHP meetup group.

I was working with Silex, a microframework based on Symfony. It's simple, small, you add the components as you need them. Gives you a great foundation, with absolute freedom - something that I much appreciate in my projects.

Everything was working great in my Silex project, until that morning. I got stuck with an upload problem (who never?), and the error message was anything but informative: "The file 'myimage.jpg' is not valid".

OK, so my image is invalid. In my conception, this means that there's something wrong with the image file, or maybe the framework is not accepting that mimetype for uploads - is there any configuration file where I had to enable it? Tried another JPG, same error. Tried a PNG, same error. Naturally, from the error message, I assumed it was not environment-related. If that was the case, the message should be clear, like "hey, you have a permission problem in your upload folder", or something.

After making tests with other images, it became obvious that the problem was, indeed, environment related: small images would work just fine. Then I checked my php.ini and fixed the problem by increasing the upload size limit.

It didn't took me so long to find out the problem and fix it, but only because I was experienced enough with file uploads to believe in my instincts and check the environment. The error message was confusing. It would be tough for an inexperienced programmer to discover the problem.

Taking Responsibility

Considering all this, I went to the #silex-php channel on IRC to report the situation - although this wasn't a critical problem, I still felt like it was my duty. It was one of the first times that I talked into the open channel. I re-wrote the sentence at least 5 times before hitting enter, because, you know: I didn't want it to sound like a complain, I just wanted to give a friendly "heads up" to help making Silex better.

After an endless moment of suspense, Igor Wiedler - one of the major Silex contributors - answered me in the channel, and his answer totally caught me by surprise: "Can you make a PR? That would be great".

Took me some seconds to realize that, by PR, he meant a Pull Request. Because, by that time, I'd never made a Pull Request in my life; I've only heard about it. And yes, I shared code before, I had at least one open source repository on GitHub with some sort of library I wrote, but I never had contributed to someone else's open source project.

Contributing is different from simply sharing some code you wrote on a public space. It's another person's project; you have to follow its guidelines, you have to ask for permission, you have to work around something that is already there. It requires communication and teamwork. Also, with a popular project like Silex, there are more things involved: many people are already using it on production, so you have to be very careful with what you implement or change.

Things got even more interesting (not to say scary) when he told me I would have to PR the Symfony project, since the problem was on the HtttpFoundation component, from Symfony.

So, all of a sudden, I had this challenge in front of me; and I felt responsible, because I was using that project. It helped me being more productive and get things done faster. Saved my precious time, and I didn't have to pay a single dime for that. I really wanted to help, even if it was just a little contribution. At the end of the day, it seemed to be something really simple, right? Just find a way to show better error messages for file uploads.

But I was afraid. My first thought was "how can someone who never even used Symfony before, can contribute and make a pull request to such a big and important project?". I was afraid of what people would think about my code. They would judge me. What if I wasn't good enough? What if I did some stupid mistake, and they started making fun of me? And worst: what if, by doing something wrong, I ended up hurting the image of women developers? It might sound silly, but if you ever were part of an underrepresented group, you know the feeling of having all eyes over you. It's an additional layer of pressure.

Overcoming the Fear of Failure

Today I know that those fears were not exclusively mine; many other developers, even the most experienced open source contributors, had to overcome the same fears before. The fear of ridicularization, the fear of not being good enough. Fear of failure. Today I also see that those fears come from a lack of confidence, perfectly normal for anything that you are about to do for the very first time. Regardless of the fact that I was programming for years, that situation was new for me.

Luckily, I've always been a very optimistic person - the rational type, at least. Some people take it for courage, but I don't think so. It's just a certainty that we are capable of accomplishing pretty much anything we want, as long as we really dedicate ourselves to it. Despite of anything else, I was a PHP programmer, and I had the skills needed for the task. I could do it. And if I was unsure about something, I could always ask for help. That's the best thing about the PHP community, in my opinion: there are so many good people, really friendly and helpful.

With that in mind, I started coding. It should not take so long, but I was full of doubts: what is the best approach for doing this? Is this good enough for Symfony standards? How should I name this variable? And so on, and so on. No matter how simple it seems to be, these questions will always pop up, but that's a good thing: you want to do your best. And that's the moment when you can use the fear of failure in your favor - to keep you alert and conscious about what you are doing.

When I finished my code (and not before making dozens of manual tests to guarantee it was working fine), that's when I realized: coding was the easiest part of everything. Of course, it's just programming, what I was used to do for many years. So far, nobody had seen my code; the moment of truth has come, when I was about to actually create the Pull Request.

The Moment of Truth

For a big project like Symfony, contributing is not as simple as creating a PR to the master branch. There are rules. You need to choose the right branch. You need to rebase (update the codebase, because something might have changed since you started coding). You need to provide informative commit messages and answer some questions in the Pull Request, like: Is this a bugfix, or just an improvement? Are there new docs for this? Are the unit tests still passing?

The good thing is that, in a big project, the rules are usually very clear, and well documented. The bad thing is that, sometimes, it's not easy to determine whether something is a bugfix or a new feature, for instance. If you start coding in the wrong branch, you probably will need to rebase everything on the right branch afterwards, which can be messy and painful.

As you can imagine, my first try went all wrong - I requested to merge a code based on master, on a versioned branch - which resulted in thousands of commits in the diff. Second try was not right either, I rebased my code but it didn't work well. Closed both (there's no way for deleting a Pull Request, unfortunately). Third try seemed to be all good - the right commits, only my changes, the diff was exactly how it should be.

Then I started getting feedback. I got a feedback from Fabien Potencier himself - the man, the legend behind Symfony. He suggested an improvement(Figure 1), and I did it. Eventually he said I would have to rebase (oh, the horror) my code and make the pull request in the master branch, since it was a new feature.

Figure 1: Fabien's Feedback

The fourth pull request was the one. I remember as if it were yesterday: in the morning of April 22, 2013, I got an email from Github saying my pull request was successfully merged. I made it to the list of Symfony 2 contributors. Even though my contribution was very simple, my name is there, as you can see in the page And if you ever get the exception "The file 'somefile.ext' exceeds your upload_max_filesize ini directive", remember: I've put it there.

Figure 2: PR Merged

The Learning Continues

The learning process didn't stop when my pull request was merged; afterwards, Fabien merged a new commit with an improvement to my code, making it more concise. Again, I learned something knew, and I didn't forget.

There's one thing we need to remember about code: usually there are many ways for solving the same problem. And something we need to remember about people: they have different opinions, and you will never be able to please everyone. You need to know how to weight the feedbacks you receive - some of them might be conflicting, and then you'll have to rely in a trustable source. I relied on Igor, since he was the person who made me work on this pull request in first place. He helped me make my code better, he helped me overcome my fear of failure, and I will be forever grateful for that occasional problem I faced on Silex file uploads.

To feel more confident about anything in life, you need practice, which cannot be done without the first time. There's always a first time for everything, and it's OK if you don't get it right at first - people will understand. Don't be afraid of failure, because often that's how we learn more - when we fail. As Thomas Edison would say, I didn't fail three times: I just found out 3 ways in which that pull request would not work at all.

Contributing to open source projects is wonderful. You have the opportunity to give back to the community, working on projects that helped you being more productive, and saved you a lot of time. And you get free code reviews! How in the world I would imagine to get a free code review from Fabien Potencier? Imagine how cool is that. Not to mention that you also gain visibility; and nowadays, your GitHub profile is so or more important than your LinkedIn. It's like your portfolio.

There are many ways to contribute, it doesn't even need to be with code. You can work in the documentation, for instance - something that is usually underestimated, but has a huge importance for any project. Find a project you like, with friendly people - it's always a good idea to have a conversation with some of the project contributors, before doing anything. You can also ask you friends about some cool projects you could contribute to. There are lots of them, I can assure you.

And don't forget: there's nothing wrong in telling that you are doing it for the first time. There's nothing wrong in asking for help, when you feel unsure about something. After all, you are contributing. Any help in an open source project is important. Whether if it's code, documentation, or a simple favicon.