Pre-order your Jewelbots Today!

Yesterday the Jewelbots team hung out at Maker Faire NYC and took part in a panel titled “It takes a Village”, a look at how we use each of our diverse skillsets to build Jewelbots (spoiler alert, the Jewelbots team is awesome).  During that panel, we also announced the opening of the Jewelbots store, where you can pre-order your Jewelbot (and buy multiples!).

If you backed our Kickstarter, this is a chance to grab more; and if you missed out on our Kickstarter, this is your best chance to be part of one of the first production runs of Jewelbots (like anything else in the manufacturing world, it’s first come, first serve; and manufacturing can be cruel if you wait too long).

Another bonus for you (and for us): if you pre-order is that it has the potential to make the lead time shorter. It makes sense when you think about it; a manufacturer that is getting paid for 20,000 orders is going to place that at a higher priority than 5,000 orders.

Anyway, I’ve talked long enough; if you haven’t already, visit our Jewelbots store, and pre-order your Jewelbots today.

And if you think that Jewelbots aren’t your Jam, I give you five reasons to be excited about Jewelbots (even if you aren’t a girl).

Being Vulnerable

I’ve made tons of mistakes over the years.  We normally call them bugs, but since around half had to do with code and half with human beings, we’ll label them as mistakes. It’s funny, I never remember bugs I’ve created and fixed in code (unless production went down) but I always remember social faux pas or missteps I’ve made. Maybe that’s because I can’t fix them after they’ve happened.  There’s no source control, no continuous delivery system, nothing to repair the damage except, “I’m sorry. I won’t do that again.”  The damage is still there, the bug isn’t fixed, there’s just another guard clause added to hopefully not trip it again.

I don’t say this to minimize the value of an apology.  If anything, it makes me want to learn how to apologize better, since I know it’s going to happen at some point, no matter how hard I try.

I wasn’t there five years ago.  Five years ago I was sure of myself, my ability as a programmer, and most definitely the best estimator I’d ever encountered.  I was that good. So good in fact that I kept the Army-induced confidence in all of my conversations, even when there were internal doubts.  I will say this for the Army, they know how to make you feel confident about your abilities.  It’s easy to dismiss most business ‘crunch time’ as it doesn’t really come close to what I went through in the military.  That disparity made me confident, and that confidence made me arrogant about my abilities.

And then that arrogance came crashing down all around me.

The project itself was a new piece of software for the company I worked for, on a project where I was the sole day-to-day back-end developer in a new language and new framework, and I had no idea what I was doing, but I was too arrogant and too scared to tell anyone else.  Today, that amount of code I wrote would have taken a quarter of the time, but then, not knowing anything and not even knowing the right words to search for, and being too scared of showing my vulnerability to ask others, I just plowed right through it. I didn’t ask for help, didn’t say to anyone that I was ‘in over my head’, and I didn’t show that vulnerability to anyone.

It’s no surprise then that everyone started to notice that the project wasn’t finished yet; that we were behind, and that I wasn’t as good of a programmer as I had led others to believe (arrogance masked as confidence has serious side effects).  At that point, the damage was done.

Trust is the glue that holds software teams together.  My teammates had to trust that I’d tell them when I needed help, or when  I was in over my head, or when I’d over-promised. That trust was broken because I was scared of being vulnerable.  Ultimately, It took a lot of time to repair that trust; but even with all that effort; there would always be that mistake.  Unlike a bug in my code, I couldn’t just fix it, check it in, and never have to think about it again.

I thought vulnerability was a weakness.  It wasn’t. It was the key to trust. It was the key to feeling like I was part of the team. It was key to delivering the product on time.

Ever since that incident, I’ve taken great care to be more open and vulnerable to my teammates, even going so far as to saying very clearly in interviews and team meetings what I’m good at and what I have no experience doing.   To break down the fourth wall for a moment, this is the point where I should talk about the list of things I’ve done; or how you can be a better software developer, or person, or whatever.

But I don’t have a checklist. I don’t have bullet points. I don’t have any insights, except to say that I’ve fully embraced being vulnerable. I never used to be OK with talking about my weaknesses, and now I wonder if I talk about them too much.  It hasn’t negatively affected me yet, but that fear is always there that it will.

Vulnerability means constantly reassessing my abilities; and focusing on my weaknesses.  It means sharing that with my teammates.  While there’s always a fear of rejection when I do that, it’s far better than the alternative.

Army Lingo (or: Stuff I’d forgotten about the Army)

I loved my time in the Army, but I’ve forgotten a lot about it;  Every now and again, pieces rise up into my brain, and I want to record them.  Since you’re an unfortunate reader of my blog, you also get to be a part of this process.

First up, some lingo we used in Emails that (upon reflection) makes no sense at all.


This stands for “All Concerned”, and was used instead of ‘Hi’, ‘Hello’, or ‘Subordinates’ to start an email.  Since being personable is frowned upon in the military, and “All Concerned” is just far too much to write (and seems a bit dry), why not replace it with an acronym?

At the end of the email, you’d generally also see /s/, in context:


Friday will be mandatory fun day.

J.A. Obvious, CPT, USA

The /s/ block meant “Signed”.  Since email’s generally aren’t ‘signed’, this was to signify that you should pretend that there’s a signature there.  Never mind that it came from Capt. Obvious’s email address (or that of his office).

In the military (I say Military since this is a DoD thing, but I’m focusing on the Army, since that’s where I spent my time), everything you do requires an order.  If you’re going to spend more than a few minutes outside of your Duty station, you need an order (or a Pass) sending you there.  In some cases, you’re ‘ordered’ to go on Temporary Duty at a specific location (we’d call this “Business Travel” in the civilian world”); and yes, you need “orders” to go on TDY.  Besides it being the paper trail of where you’ve spent your time, it’s also used for funding.  Everything in the Army you do has a funding code. Everything.

4-Day Pass:

Also known as the ’96 hour’ pass.  It’s generally ‘time off’ that has to be granted by the Commander of your unit.  It also generally has a radius attached to it (150 miles is what I remember; some units it’s less, other units it may be more).  If you’re caught outside this radius or don’t get back to your duty station if you’re “recalled”, then you can be punished.  It’s also worth noting that it’s never actually a 96 hour pass.  If you have a ‘good’ unit, then you have from Reville Thursday Evening until First Formation on Tuesday Morning.  If you have an asshole for a Commander (or First Sergeant), then it’s from 0600 Friday morning until recall formation Monday evening at 1600 hours (4pm, Americans).

NJP / Article 15 / Captain’s Mast

Non-Judicial Punishment.  Article 15 is the ‘article’ in the Uniform Code of Military Justice that governs NJP, and the “Captain’s Mast” is the Navy equivalent (I think Marines had “Office Hours”, but they might also have used the term “Captain’s Mast”. I can never remember). In the military, you can either be punished through some sort of Court martial (there are several levels depending on the severity of the offense); but since that’s a rather permanent stain on your record (if you’re still in after the Court Martial), your Commander has the option to ‘bring administrative action’ under Article 15.  Effectively you have no counsel, no way of defending yourself, and you’re generally punished either through restrictions, extra duty, or docked pay (You can confer with counsel; but not be represented by counsel; and counsel will almost always tell you to take the Article 15, since your alternatives suck that much more).


We used to make fun of the acronyms we had to learn and use; and we generally referred to them as “TLAs”, “Three letter Acronyms”, which itself is an acronym; so there you go.

What acronyms/lingo do you remember from your time in the military? Or maybe some other organization?

Overworking is destructive

I’ve long been a fan of the eight hour burn.  Here’s what I wrote about it in March:

Thinking about Developers, we tend to work very long hours, even though it empirically hurts us and the company. Extreme Programming tried (and failed, sadly) to introduce the notion of the Eight-Hour burn; a reasonable spin on what programming should be. But with distractions aplenty, it’s hard to justify an eight-hour burn.

The eight hour burn is meant to combat those behaviors that seem helpful to the company, but are ultimately destructive to the individual and the company.  This centers around programming beyond 40 hours for any reason, especially:

  • launching the inaugural product
  • feeling passionate about the product/project/mission
  • to catch up with the promises Sales made
  • to beat a competitor to market
  • moving fast and breaking things
  • to show the company you’re a “team player”
  • because you have x months of runway left
  • because you are in over your head and don’t want others to realize it

The trouble with each of these reasons is that they’re easy to rationalize.  “Oh, I’m only working 60 hours a week until the product is launched, and then I’ll take a vacation.”  or “Oh, if only I put in a few more hours each day, I’ll learn this faster.”   And not all rationalizations come from developers; some come from the powers that be: “We need this feature so we can sell to Enterprise companies; and since we promised we had it, I need you to deliver it before they finish implementing our software. You have four weeks.”

Some rationalizations are even so basic that they’re sacrosanct: “We move fast and break things.” “We work hard and play hard.” “We need to beat our competitor to market or we’ll lose.” “We need all hands on deck to ship this product before Q2 ends.”

At some point, these rationalizations for over-working will cause you to burnout. You’ll start to slow down, spend less time on work, and ultimately either be put in a performance improvement plan, reset and get out of the burnout, or find another job.

Besides the extreme examples of what happens when you overwork (burnout), there are other side effects.   Fixing bugs created during the course of a 60+ hour week.  Designs produced during late nights are found to be logically flawed the next week.  Frustration, fatigue, and arguments that shouldn’t break out (but would seem to be that much closer to the surface).

In my case, it wasn’t a push from above or a shortened timeline that caused this. Our CEO makes sure to tell us to take time to recharge, that this is a marathon and not a sprint.  She wants us to stay healthy and not burn out, but even with her total support, I found myself working 50-65 hours a week, working through vacation, and even working in my sleep. I believed in the eight hour burn, but I had the hubris to believe that the destructive effects of overworking “wouldn’t happen to me”.

We have met the enemy and he is us.

So what can we do? How do we turn this into a happy ending?

For leaders, this means paying close attention to your subordinates.

  •  If you notice commit messages spanning lots of hours, or late night emails after having seen them working all day, ask about it.  “You seem to be putting a lot of hours in; how are you feeling?”
  • If they say they’re taking vacation, make them take vacation. Make sure they know they should be unplugged.
  • Don’t encourage a culture where late night emails garner responses.  If you send an email late at night (perhaps you shouldn’t?) then explicitly state that you don’t want action on that email until a reasonable time.
  • If you have DBAs or Ops, make sure they’re cycled through production support or system administration. Treat those operations like hazardous duty: They hould be well compensated and not spend an inordinate amount of time in that rotation.
  • Encourage subordinates to keep a reasonable work pace.  This doesn’t mean ‘go slow’; it means “Don’t break your neck when there’s no reason to.” There will always be fires; but the person you’re sending to fight the fire should be more valuable to you than the fire itself.  If that’s not the case, your priorities are askew.

For us as professionals, this means:

  •  Setting our own boundaries.  Passionate should never mean “going to burn out in 6 months.”  We’re good enough, even if we’re imposters. Work is work, but you should have something outside of work that keeps work from overtaking your psyche and your life’s energy.
  • Learning to say ‘no’.  This one is really difficult for me. I want to say ‘yes’, I want to be valuable; and saying “no” doesn’t seem like it makes me valuable, right? Not so fast.  Being able to say ‘no’ when the situation warrants it means your leaders don’t have to weigh opportunity costs; you’ve already done it for them.  It means they don’t have to worry whether you’re taking on too much — you’re telling them when that’s the case. It means they never have to worry if you’re going to “over promise and under deliver” because you don’t.
  • Work an eight hour burn.  It’s easy not to do this; because our default state isn’t action, but with some changes on our side, we can.  I’ve started to use stayfocusd to ensure I’m not spending random time on twitter. That article is full of great suggestions, and I’m incorporating them into my life.
  • Live a complete life.  There’s an old saying, no one on their death bed wishes they spent more time working.  You spend (maybe) a third of your life at work; should it account for all of your energy?

What are your tips for combatting burnout?