Skip to main content
Ben Nadel at cf.Objective() 2011 (Minneapolis, MN) with: Brandon Moser
Ben Nadel at cf.Objective() 2011 (Minneapolis, MN) with: Brandon Moser ( @brandonmoser )

On Staying Focused And Productive In The World Of Programming

Published in , , , Comments (33)

Last night, Michael Calkins asked me how I felt about all the churn in the JavaScript world. And, specifically, how I stay focused and productive. It's an interesting topic, especially given the light of some rather controversial posts on the state of web development. I definitely do have some strategies and structure that I use; but, to be clear, I have just as many insecurities and moments of "impostor syndrome" and fears that I'm a horrible programmer as the next man or woman. After 15 years of programming, I'm just trying to accept that those fears never go away; and, the best that I can do is to keep moving forward, trying to improve myself at least a little bit each day.


Michael Calkins asks - how to stay productive and focused.  

The following is a list of techniques, approaches, and mindsets that have worked out OK for me so far. Your mileage may vary.

Structure In Life Is Critical

I'm an introvert. I love people, especially programmers; but being social exhausts me. I don't adapt well to change. If there's a dinner reservation, it needs to be made at least a day in advance so that I have time to mentally prepare. For me, having structure in life is the only way that I can function at a meaningful level.

I go to sleep between 9:30 and 10PM and I wake up at 5AM. I did sleep in a little bit between Christmas and New Year's, which was luxurious. But, other than that, I keep the same exact waking schedule 7 days a week. By keeping my "awake hours" consistent, it allows me to build structure into the rest of my day and allows me to actually plan out my time (although I tend to really live day to day in terms of long-term planning). More than anything, have structure just makes me feel comfortable and relaxed. And, when I'm comfortable and relaxed, I'm most productive.

Have Dedicated Time To Learn And Research

With my consistent and predictable schedule, I can actually plan to have "deliberate practice" (ala Geoff Colvin in "Talent is Overrated" and Malcolm Gladwell in "Outliers"). After I wake up and shower, I sit down and I partake in deliberate practice from about 5:30AM to about 8:30AM. Often times, I am working towards writing a blog post. But, I'm also happy to just read up on a topic, or watch a video, or experiment with some new code.

When I was a bit younger, I think that I focused too much on trying to write blog posts. This caused me to shy away from larger topics that would inhibit my ability to produce posts. But, as I've gotten older, I've embraced the idea that the learning is more important; and, that if I can't write a blog post for a few days, such as when trying to wrap my head around Redux, that's OK. Life goes on.

There Are No Days Off From Learning

There are days off from my job; but, there are no days off from my learning. As I said, I keep the same sleep schedule 7 days a week. Which means that on Saturday and Sunday, I'm up at 5AM (with my alarm clock) and at my desk learning from 5:30AM to [at least] 8:30AM. It's not always easy, but I think the consistency and the structure is critical.

Additionally, I always have a podcast ready to go. Whether there's a car ride to the market or a long dog walk, if I'm going to be away from my desk (and alone), I have a postcast to listen to. It doesn't even have to be about a technology that I use (ex, Ruby Rogues); when you listen to smart people talk about solving problems, you will learn something!

Always Have Something To Learn

Whenever I think of something to learn or to research, I email myself. Immediately. I have a special filter setup in GMail that looks for a specific subject line and then filters those emails into an "Research & Development" inbox. This way, I always have a queue of topics that I want to dive into when I have some free time. These aren't broad topics like "Learn Redux"; rather, they're small, action-oriented topics like "try moving Redux middleware into provider configuration phase."

I don't necessarily tackle these items in a top-down manner. I pick the right one for my mood and general level of energy. If I'm particularly tired, I choose a topic that feels easy (or more emotionally satisfying). When I'm energized, I pick a topic that feels more challenging and intimidating.

Writing About It Helps Remember It

When I trip over something in programming, I write about it. When something surprises me, I write about it. When I'm just excited to have used a new feature, I write about it. I try not to write something that simply echoes the documentation; but, other than that, no topic is too small, too esoteric, or too boring to write about. Writing about technical detail is a wonderful way to build out a strong mental model that actually sticks over time. I attribute my ability to remember detail to the act of writing.

Err On The Side Of Re-Inventing The Wheel (At First)

When I face a new challenge or have to deal with a 3rd-party API, I try to write custom code for it before looking to see if there's an existing library that supports it. Yes, a very large part of this is done because I just love and want to program. But, I honestly do think that this approach helps me learn more about the topic at hand. It's how I've learned about signing requests and generating message authentication codes and producing cryptographically-strong random values and serializing JSON Web Tokens and implementing Base32-encoding by using bit-wise manipulation.

All of those things (and many more) could have been done through some library call. But, I wrote the code that implements them. And, I learned a lot while doing it.

Of course, I don't always get it right. Or catch all the edge-cases. Or can even figure out how to implement the dang thing. And, at that point, I use a [hopefully vendor-supplied] library. I have nothing against using a library; I just enjoy trying to write the code first.

Harden Existing Skills Before Learning New Ones

In the world of programming, there's a ton of churn. And, a lot of people who enjoy nothing more than immediately jumping on the next hot technology. I try to avoid new technologies, for at least a while. I try to harden my existing skills before trying to solve a problem with a new technology or methodology. They say, "choose the right tool fo the job." But, the way I see it, the tool that I know best is going to be the right tool, even when it's suboptimal.

Enjoy The Game Of Being Prideful About Your Language / Framework / Technology

Nobody likes a zealot. And don't be close-minded about other technologies or frameworks. They're probably all great. But, I do think there's a lot of value in "playing" at being prideful. If you see another language or framework do something cool, "playfully take the stance" that your language or framework is better. And then sit down and figure out how to use your language of framework to accomplish the same thing. You'll learn a ton along the way. You'll force your brain to think differently. You'll challenge your preconceived notions. The "power of constraint" can be a magical tool for learning.

Always Be Able To Explain Your Choices

Albert Einstein said, "If you can't explain it to a six year old, you don't understand it yourself." In the world of programming, I try to borrow this mentality when it comes the choices I make. Whenever possible, I try not to make a choice unless I actually understand why I'm making it and can explain the value to someone else (if I had to).

Take Immutable data for example. People love it. They're crazy about it. But, I have yet to use it because I can't point to anything in the code and explain the value-add of Immutable data. And if I can't explain why I am doing something, I don't do it. Or, I embrace the fact I have no idea why I'm doing it and just go with it until I'm smart enough to make an informed decision.

Now, this doesn't mean that my decisions are always right. My thinking and my methodologies have changed a lot through my career. Decisions that I thought were awesome - and that I could explain at the time - turned out to be unfortunate choices. But, that's just the learning process.

Read The Documentation

For me, there is no better source of learning than actually reading the documentation or the books on a topic. I remember when I first got into ColdFusion, I woke up ever morning and spent time reading the "ColdFusion MX Bible". It probably took me weeks; and a lot of the information never got used (LDAP? What the heck); but, at the end, at least I had a sense of the entire landscape of the language. Similarly, when I learned AngularJS 1.x, I poured over tutorial and most of the documentation. (I hope to do the same thing with AngularJS 2.x quite soon).

Even if it doesn't all make sense at first, I think there's value in at least getting a sense of what is out there. It helps you understand what is possible so that, later on, you can have some inkling in what to do or where to look things up.

Read The Source Code

While I love documentation, it's not always clear. When in doubt, read the actual source code. I can't even being to tell you how many marvelous gems you will pick up from reading the source code of a library or a framework. Not to mention that it will actually teach you how something works.

There's not a week that goes by where I don't open up the AngularJS framework vendor code and dig into how the AngularJS team implemented something. It never gets old. And it's always inspiring.

Be Intensely Consistent In Your Coding Style

I am a maniac when it comes to code consistency. I have a style that I like to follow and I act as if the consistency and adherence to that style is as important as the quality of the code itself. Consistency is part of my DNA. When I look at code that is inconsistent, I can feel it my gut. It makes my uncomfortable. I need to fix it. I have trouble even writing "throw-away code" that has inconsistent formatting because it makes me twinge.

I truly believe that when you are maniacal about consistency, the quality of your code gets better. Bugs are either prevented; or, they are much easier to find because they usually stand out as a blemish upon the beautifully organic shape of your syntax tree. I also think that once consistency is a first-class citizen, writing code becomes faster because there are many things that you don't have to think about - they just happen automatically.

Of course, my personal style has changed a lot over time (Hungarian notation, what was I thinking?!). But, that doesn't mean that I am any less intense about my consistency at any given moment in time.

Don't Over-Tool Your Development Workflow

When you go to the gym, you can either use gloves; or, you can build calluses and force your body to adapt to the stress and strain of steel knurling.

In programming, I view tooling in much the same way. I use Sublime Text and the only plugin that I have is for syntax highlighting. I don't use linting. I don't have any documentation plugins or code insight. I don't have unit tests constantly running in the background. I don't have any refactoring tools. I don't use snippets or macros. I have, what is basically, a really high-performing, developer-friendly text editor.

This approach forces me to look stuff up. The reason that I know, off-hand, that "minutes" in the dateAdd() function are represented by "n" not "m" (since "m" is for "months") is because I've had to look it up a whole cat-lot of times. And doing so has built up a callus in my brain that now retains that information. It's the same reason that I know that the RegEx pattern is the first argument in reMatch(), but the second argument in reReplace(). These rules are a part of my being now - they're how I see the world.

I am sure you could try to argue that this approach makes me horribly inefficient. The same way that you could argue that one should always wear gloves in the gym. But, all I can tell you is that I enjoy it. I don't see it as a problem or a barrier to efficiency. But then again, I don't wear gloves in the gym and I love calluses.

So, that's how I get through my day. This might connect with some of you and seem completely off-putting to others. I think we all have our own way of approaching life and learning and we all have our own strategies for success. These are my strategies.

Reader Comments


Great advice all the way around Ben. I need to start adapting some of your writing habits in order to write another blog post since the one where I said I should write more :-).


Thank you for writing this. As a junior web developer, it triggered so much motivation, reading that senior developers, too, face insecurities about the code they write and feel overwhelmed when trying a new technology. Very insightful.


Hi Ben,
Your last point particularly caught my attention: after years of java programming on eclipse, I realized recently that I couldn't code without auto-complete or snippets. I then dumped eclipse (as well as java for that matter !), and started to code with vim, and now atom. I feel a huge difference as it helps me to memorize and understand what I do.
A big thank you for this brilliant post: you're the living proof that humility and eagerness to learn are probably the most important characteristics of a successful developer !



I have tons of insecurity. Take AngularJS 2.0 for example. It went into Beta weeks ago, and I still have yet to take a look at it. I've been busy, but I know that a large part of that is that I am nervous about how much will actually go into it (what with trying to learn TypeScript and getting all the transpiling and what not setup). I'm going to go from someone knows a TON about AngularJS 1.x to something who knows NOTHING about AngularJS 2.x .... and its going to be extremely humbling.



Absolutely my pleasure to share. Vim is some intense stuff. There are some people who use it at work and watching them use it on screenshares is so interesting. I still need my GUI. When I go to the command line to edit things, I have to use `nano` so that it has the commands at the bottom :D



Some really good points here. I think that a commitment to lifelong learning is at the core of transforming yourself from a person who can code into a developer. Reinforcing what you're learning is super important, as you mention, and is why I got into teaching in the first place. I wasn't a subject matter expert when I taught my first ColdFusion or Flex course! But the questions helped me to broaden the scope of my knowledge and made me a better developer, every time! And it wasn't a one-time occurrence, either. I learned something new every time I stood at the front of a training room. I'm working to get back into the classroom now that I've decided on a direction, and I honestly can't wait!



You bring up a great point about teaching and getting asked questions. I see that at work all the time; we'll be discussing some problem and someone asks a question and I'm like, "Hmm, that's a great question - I don't entirely know." And blamo - something new to look up and learn. Trying to explain stuff to people is a wonderful source of new input and inspiration.



We're really all just hackers at heart, aren't we? I think we need to retake that term, since it's seen in such a negative light these days.


Thanks for writing this. I do enjoy insight into how others organize their days.

ditto - re: always having a podcast ready to go. There's so much fun stuff to learn and do, but so little time (to waste).

regarding your emailing yourself, I use to do the same thing but about 2 years back started using todoist ( and find it far superior in several ways.

1. It's desktop, mobile, and web app based (+ browser & gmail extensions),
and your list seamlessly syncs across all of them. So I always have access
to my list.

2. I use project folders (Angular, Meteor, ColdFusion, etc) and tags (read,
watch, listen, tutorial, etc) which help me find those things I'm in the
mood for (e.g. watch + angular). I even tag them for expected time
commitment (5m, 15m, 1h, 1d) so I have a decent idea what I'm getting
myself into as far as time commitment. If I only have 15m, I know how
to find those things which can be done quickly.

3. It allows you to set a location for particular tasks, so you can label things
for @home or @work and those can alert you when you're in those areas.
I don't actually use this, but nice to have.

4. Obviously you can set date, date + time, and alarms for those time critical

Those are the key things that come to mind. As well, your mileage may vary, but seems like you might also get a productivity boost from this app.

BTW, I am in no way affiliated with todoist nor would I benefit in any way from you or anyone else adopting it... except that maybe the more successful they are the better they make their product. All boats rising!


@Ben, if you have any questions about TypeScript, SystemJS, RxJS all tools around Angular 2 I'm glad to help. Make sure to checkout JSPM as well when you would use SystemJS as module loader in your Angular 2 applications.
I learned a lot about these the last half year and I'm sure you'll enjoy the learning journey!
Thanks for all your inspiring posts and respect for all the effort you put into them. You made/make me a better developer every post ;)


Hey, great post. I really like the idea of a very minimal text editor. Can you share what plugins that you do use. I have stripped away all of my plugins so I force myself to rely on myself and not crutches. Thank you.


Great stuff. I like your ideas on keeping a consistent structure every day of the week.

I've had some success with using the mobile app 'Seven Weeks' to track that I consistently perform certain tasks (eg. coding every day), to help build the habits. A lot of people, myself included, find them hard to form.

On the subject of minimal editors, I find I often have a deeper understanding of the project structure than other teammates because I will go and find a file, rather than asking the editor to find it for me.


Some excellent points, but I can't agree with you in regards to trying to write established frameworks first and using a basic text-editor to develop.

When I code, my company is paying me to get a job done. Yes, there is a ton of crap third-party libraries out there, but the creme rises to the top. As a seasoned developer I know how to pick out an Underscore from a less reliable library and understand that the code I would write would cost more to the company and not work as well. Libraries, if they subscribe to the methodology of doing one thing, and doing it well, will provide better code-coverage and efficiency than what I'm building to supplement a business requirement.

I use Visual Studio Code and run a bunch of Node threads watching my code. It's more efficient for me to have tools to tell me when I'm wrong, or provide me with a list of options, than to continuously fail and research. To me, building the product is the goal. Of course you run into scenarios where you fail, or need to research an obscure piece of a language (hell, I've had to use reflection tools on the SharePoint SDK to re-implement locked classes) but I can't waste time on the nitty-gritty. Using your date example -- I write in so many languages with so many different Date paradigms that it's a determent to myself to learn them all. My focus is on building a structural foundation for a product. I could either architect a system, or beat different semantics into my head.

You're not wrong. This is all subjective. But what I would tell aspiring developers is to be able to move up the ranks it's far more important to understand concepts, and as you grow, start looking at problems from a higher view. We all start out with "how can I do X in Y language", but then we graduate to "what tools would be best to implement X". Which circles nicely to the beginning of your article -- keeping up with tech. My suggestion is not to different. I spend about an hour or two a day coding after work. It's exhausting, but it's new stuff. I take an hour in the morning to go through my RSS feeds to keep up with the industry. I haven't built an application with Flux or Redux yet, but I can tell you the concepts and why they would be useful in a given scenario. To me, that's the mark of a good developer. Rationale and problem solving ability outweighs knowing a certain language to the nth degree.



I basically only code in two languages these days: ColdFusion and JavaScript, so the landscape of syntax methods is much less for me :)

Also, as far as picking libraries, I don't want it to seem like I write everything from scratch. But, I also don't "install" everything by default. The smaller something is, the more likely I am to try and write it myself. And, for new developers, I think that's where a ton of learning opportunity comes into play.

Take for example, having to parse a file-name and extract the extension (ex: "txt" from "data.txt"). Something like that I would absolutely write from scratch. It's a fairly small task, but with many possible ways to execute - could use RegEx, could split strings, could leverage some native library (depending on the language). It's such a fertile ground for experimentation.

Right now, in today's climate, I just think people are way too eager to simply (making up module name here):

npm install filename-utils

.... to get methods that are like 3 lines long. And I just think that does the developer a little bit of disservice.

All things in measure, though. As you say, the goal is always to build the application and deliver value to the clients (internal and external). But, learning on the job will always be part of life. And, people should find a nice balance in there.



Word, I have to have structure. That said, getting up and programming is really the only habit that I'm *good* at ... that and flossing every day ;) Everything else is pretty much hit and miss.

As far as having a better understanding of the project, I agree. I know a lot of IDEs have the ability to like SHIFT-Click to jump into files. I'm not even sure if SublimeText can do that. But, it's one of those things I would likely shy away from (personally).

Now, in SublimeText, I can use the "Jump to anything" power menu, which I use constantly. But, the beautiful thing about it is that it:

1) Forces you to think about what file actually contains the thing you are looking for, which continues to build the mental model of the project.

2) Gives you random insight into the project by way of seeing files in the list you may not have known were there. Like you start typing in "File" and see, "FileHasher", "FileNameHelper", "FileSecurity" ... and you get think, "Whoa, I didn't know we had a FileHasher - what does it do and where is it used?

To me, that adds a small bit of overhead, but also adds a lot of value.



Much appreciated sir! I do love the quote as well. I also find that the quote helps with some "premature optimization" problems. Something may be helpful in a year when my application is massive and my company is wildly successful. But, if I can't point to something in the code *today* and say, "Here, here's where the value is," maybe its not worth making that choice today (if that makes sense).



Right now, I only have the ColdFusion syntax highlighter. And, I just installed the TypeScript syntax highlighter.

I actually started with the *full fledged* TypeScript plugin that did all kinds of interesting stuff. But, it slowed SublimeText down way too much. As such, I just reverted to the one that offers syntax highlighting and nothing else.

And that's it. The rest of it is just core SublimeText functionality.



Thank you kindly! I started digging into AngularJS 2.x over the weekend and am using/leaning TypeScript and ES6 as I go. It also uses SystemJS (as you know), but I only know what's in the tutorials. It's fun, but definitely WAAAAAAAY different than AngularJS 1.x. An uphill battle to be sure.


@Chris, sounds really cool. Honestly, I only use email cause it was already something I had all on devices :D Not cause it was all that great. I do like the idea of being able to Tag stuff - I can see how that would be very useful. I'll give it a look, thanks!


Damn Ben, that was an excellent and inspiring post.
I have to say though, the idea that you of all people suffer from 'impostor syndrome'?
Sheesh... You should know that you're the reason most of the *rest* of us feel like impostors from time to time!
Or to rephrase more positively: Without your blog, many of us would likely be markedly less awesome at web development... and would probably spend twice as much time solving problems that you've blogged about some years prior to us running into them.


All of this time I thought we were such different developers, but reading this post it feels like we're not only terrifyingly similar in our workflow, development, and learning values, but to some extent as humans.

You never struck me as an introvert. That was interesting. I'm sure many of your readers would love to hear a post *just* elaborating on the "being social exhausts me" line and what actually happens to you when you're up the wall against a temporary lack of structure.

There are a few exeptions.

You're better at carving out enough energy and grit to throw 3 hours at excellence every morning. I admire that in a way I can't even articulate.

I *almost* don't even see how that's humanly possible with a senior-level, full time development role, but I know it just barely is and so I believe you. I *wish* I could find a significant other that would support that kind of powerful investment.

Also, you're much better at taking your code slowly and commenting it to an extent that I've never seen before. This may just be a false impression, but from the code snippets you share ( and I'll admit that I don't read CF blogs very often at all ) it seems like you write just as many comments as you do expressions, which is impressive. I'm that naive MFer who thinks that his code is crisp and fluid enough to be as readable as a comment half of the time and who ends up paying for it later on on occasion, or maybe I just haven't matured enough as a developer yet to force myself to do stuff like this.

Also, you're much better at being able to deal with the consistent latency of OS X. I have a late 2015 15" retina MacBook Pro that's just sitting on my bookcase waiting for a few minutes of my time here and there, but I cannot for the life of me figure out how to *feel* productive on it ( and it's definitely a feeling, I've worked exclusively from a mac for months on end and half a year once when I forced myself to ). So, that I admire too. Another flavor of your self-control, because I think that there is value in exploring new things and remember you talking about how you felt like switching made you feel more likely to try new things than you did on Windows.

In closing: Your post was inspiring, which is rare for me. I'm kind of in your position in a sense, I have a compelling reason that other people would *say* should make you impervious to impostor syndrome, but it's still there, no matter what. It's always there.

I think it's easy to argue that this post proves that you're good at what you do in a way that no one can really argue with. Bravo, old sport. Bravo.


Great article!

Getting up at 5:30 and self-improving 3 hours everyday is just badass!

I do not write blog posts but do pair-program a lot and I feel like these two are similar in a way that you need to explain your choices and have to reason about your code.

Reasoning is the key to programming.

If you can reason about your code you can call yourself an above average programmer, otherwise you are still in the dark.

My best productivity tips are the following:
- forwarding all social media sites to in my hosts file
- i do lint my JS
- with every new tool -> new shortcuts to learn
- podcasts all the way! anything that makes me think
- i ditched the TODO list and now only have the research list you were referring to. i also usually pick by mood from my research list and also with an additional rule: 1 for least effort -> highest return and 1 for pushing my limits in terms of difficulty of understanding or learning the topic
- i also stopped drinking coffee during weekdays which resulted in much better sleeping patterns
+1 i stopped worrying and love the JS frameworks (understanding higher level concepts of many and deep-dive into a very few)



It's definitely not easy to fit it all in; and, there are certainly sacrifices that I've made (like going to be earlier and reading a lot less than I used to and watching less TV). And, there was a point - maybe a solid 7 or 8 months - where I didn't blog at all because "startup life" was all-consuming (and *soul-crushing*). Luckily, things started to level out again and I'm able to get back to a point where I have much more work-life balance.

Also, much of my morning time is spend before the missus and the dog wake up, so that helps with having to negotiate about it. But, she is definitely really great about me having "me time" and she understands how important this stuff is to me.

As far as commenting in code, it actually serves several different purposes:

1. It provides "white space", so to speak, for the rest of the code to have a little breathing room. When code is too squished together, I find that I have a really hard time concentrating on it or reading it. It's not dyslexia or anything like that; I think it's just that my brain doesn't know how to focus well with so much noise around it.

2. It tells a story. Many people thing the code should tell the story with perfectly names variables and methods. But, to me, the comments tell a parallel story that someone can read to get a sense of what is going on.

3. It FORCES ME TO UNDERSTAND and think about what I am doing. I can't tell you how many times I'll go to leave a comment and realize that I don't truly understand something. So, I go and do a little R&D and find out that my assumption about something were wrong. These assumption may have never been challenged had I not forced myself to leave a comment as to why I as doing something.

That said, I know that a lot of people out there *hate* the way that I write and format my code. So, it's definitely a very personal thing. :D

I'll try to write up something about being introverted. It's definitely an interesting way to experience life.



>> forwarding all social media sites to in my hosts file

... ha ha, that's awesome :D

I have to admit that one thing I would really love to do, but never seem to get motivated to do, is really learn about the tools that I do use. Take SublimeText2, which is my current IDE of choice. I basically only know a few commands:

CMD-R - Jump to method.
CMD-P - Jump to anything.
CMD-D - Select duplicate.
CMD-SHIFT-D - Duplicate selection.
CMD-SHIFT-L - Split selection into multiple cursors.
CMD-T - Open new tab.
CMD-SHIFT-T - Re-open last closed tab.
CMD-ALT-Arrow - Move left/right between tabs.

And that's basically it. With that handful of commands, I *like to think* that I am very efficient at moving around the IDE. But, I know that SublimeText2 is massively powerful. It has a built-in console and all kinds of plugins and like a million different preferences. And, I always think - Hey, I should really sit down and RTFM for SublimeText. Heck, I even purchased a book and video series on it .... but never actually read it or watched the videos.

I really wish I could motivate to just get it done.

But, as with many things in my technology life, I sometimes just don't have enough friction to make it feel worthwhile. As with my code, sometimes I can't point to my tooling and answer "What problem is this helping me solve".

As for caffeine, I need it, but don't drink it too late. Also, started taking Melatonin a few months back at night - sleeping so much better (but dreaming much less).


Hello Ben,

Thx for this great stuff. One substantial part of the secret seems to be discipline and regularity. The rest should be the genius which is hidden in your brain.

Juste one question, what kind of hardware do you use ?

Are you listening to music when you're programming ?

Greetings from Switzerland !



Great question. These are the main ones:

* Basically anything on by Charles Max Wood.
--- JavaScript Jabber
--- Adventures in Angular
--- Ruby Rogues
* Angular-Air -
* JavaScript-Air -
* Node Up -
* React Podcast -
* Hanselminutes -

There's probably a few other random ones, but those are the main ones. If anyone has any suggestions, I'd love to hear it.



I do listen to music, but for the most part, it has to be either Classical or Gregorian Monks Chanting. Or, when I really need to block out the world, I listen to the sound of a cat purring:

Mostly, I can't listen to anything with words or I find it too distracting. Unless I'm doing something really mundane / repetitive where I can rely on muscle memory more than brain activity.

As far as hardware, I'm on an iMac 27". Though, I am trying to transition to a MacBook Pro (with external keyboard / monitor) so that I can be a bit more mobile. I'd love to get out to more meetups and other dev-related events (I haven't been to anything in a long time).

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel