Archive of articles classified as' "career"

Back home

First, do no harm

13/11/2014

From a wonderful post by Matt Williams about the type of business he is looking for:

A Business Manifesto
We are uncovering better ways of running a business and helping others do it.
Through this work we have come to value:
People and interactions over profits and prestige
Quality service over quantity of service
Customer relationships over contract negotiation
Flexibility over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

In a nutshell I want to work for a company which values people — both inside and out of the company. I want to work where people strive to do things right.

When I go home, I want to be able to look in the face of my daughter and not have to make excuses for the work that I do and the effect it has on others.

Sums things up nicely (and definitely what we aspire to at Cozy, by the way we’re hiring).

It is a reason I left the video games industry. I wanted to use my skills to do something I felt was more constructive.

But more than that, I was amazed and frustrated with how the industry was run (almost as bad as films). Mass layoffs even on successful projects. Over-managed projects that go on for 4, 5, 6 years and are cancelled. Creating an exploitative product in order to milk a customer base. Huge budgets, huge marketing, appeals to lowest common denominators (often sexual). There are good companies but the business models are so insane that you can be around for 10 years and fold tomorrow.

2 Comments

If you hear “perception is reality” you’re probably being screwed

27/10/2014

I was once told in a performance review that “perception is reality.” I was infuriated, and the words stuck in my mind as the most toxic thing a manager could say to an employee. I have avoided writing about it, but the “This American Life” episode about Carmen Segarra’s recordings at the Fed has inspired me to change my mind. Here’s the relevant section, emphasis mine:

Jake Bernstein: Carmen says this wasn’t an isolated incident. In December– not even two months into her job– a business line specialist came to Carmen and told her that her minutes from a key meeting with Goldman executives were wrong, that people didn’t say some of the things Carmen noted in the minutes. The business line specialists wanted her to change them. Carmen didn’t.

That same day, Carmen was called into the office of a guy named Mike Silva. Silva had worked at the Fed for almost 20 years. He was now the senior Fed official stationed inside Goldman. What Mike Silva said to Carmen made her very uncomfortable. She scribbled notes as he talked to her.

Carmen Segarra: I mean, even looking at my own meeting minutes, I see that the handwriting is like nervous handwriting. It’s like you can tell. He started off by talking about he wanted to give me some mentoring feedback. And then he started talking about the importance of credibility. And he said, you know, credibility at the Fed is about subtleties and about perceptions as opposed to reality.

Well shit, if that doesn’t sound familiar. Here I was, doing work that was by all measures extremely successful, yet pulled into a feedback meeting to be told “perception is reality.”

Let me tell you what “perception is reality” means, and why you should plan on leaving your job the moment you hear it:

The arbitrary opinions of your manager’s manager defines your situation. And they don’t like what you’re doing.

Your manager may be well-meaning (mine was, as was Mike Silva), but at the point you get this “perception is reality” bullshit, you can be sure there’s nothing that they are going to do to help you. Someone above them has taken notice, your manager has probably heard hours of complaints, and you can either shut up or get out. Perception isn’t reality everywhere; it is only the mantra in sick organizations totally removed from reality.

1 Comment

Keeping talented employees

18/09/2014

I saw a tweet the other day about the eight things that keep talented employees:

I’m normally not a fan of reducing human behavior to a list like this, but it seems pretty complete, and the words resonated.

As a technical leader I am a fan of metrics and dashboards: tests passing, code coverage, static analysis and metrics, velocity, bugs, takt time, and other indicators that you wouldn’t focus on individually, but are very useful collectively.

I wonder if, as a manager, assuming trust is in place, is it worthwhile to go over these things explicitly? To make a “private dashboard” to cover in 1-on-1s, and see where the problems are?

  • If everyone is not feeling challenged, why is that? Is it because the work is boring? If so, why? Is it temporary grunt work that can be augmented with some side projects? Or is the product becoming less exciting to work on?
  • Who doesn’t feel like they’re on a mission? Is it because they are disillusioned, or is the mission bullshit. Are more people disillusioned each month?
  • Which individuals are trending up and down? Is the organization as a whole trending up or down? Which attributes are trending up and down? For all these questions, you must answer “why“!

I’m not sure this is something I will start using immediately, since I am just getting to know my team and I don’t want overly formal process to get in the way of a human connection. But it’s certainly something I would have done at CCP. It’s very convenient for bad managers to rationalize poor ratings, but perhaps some tracking on these eight points can be a start towards providing quantitative evidence of employee satisfaction.

1 Comment

Escaping the Windows prison

8/09/2014

My friend Brad Clark over at Rigging Dojo is organizing a course on Maya’s C++ API (I am assuming it is Maya but could be another program). He had a question about student access to Visual Studio, to which I responded:

As a programmer, the experience on Windows is pretty horrific. No built-in package manager. A shell scripting language designed in hell. A command line experience that is beyond frustrating. A tradition of closed-source and GUI-heavy tools that are difficult or impossible to automate. A dependence on the registry that still confounds me.

My eyes weren’t opened to this reality until I switched to Linux. I was on a Windows netbook that was barely working anymore. I installed Linux Mint XFCE and suddenly my machine was twice as fast. But the much more important thing that happened was exposure to modes of developing software that I didn’t even know existed (Python, Ruby, and Go made a lot more sense!). Programming in Windows felt like programming in prison. Developing on Linux made me a better programmer. Furthermore, If I didn’t end up learning the Linux tools and mindset on my own, working in the startup world would be basically impossible.

Programming on Windows revolves around Visual Studio and GUI tools. If you need evidence at how backwards Windows development is, look no further than Nuget. This was a revolution when it was released in 2010, changing the way .NET and Windows development was done. In reality, the release of Nuget was like electricity arriving in a remote village. It took ten years for C# to get a package manager. And it is for the rich villagers only: older versions of Visual Studio don’t work with Nuget.

The ultimate problems Windows creates are psychological. The technical differences change the way you think. It echoes the “your Python looks like Java” problem. Is the Windows mentality what we want students to take on? My last two jobs have been on Linux/OSX. I honestly cannot imagine having kept my head above water if I didn’t have a few years of self-taught Linux experience.

Windows still dominates in desktop OS popularity. That is all the more reason to make sure we are exposing student programmers to alternative ways of developing. I want new developers to be exposed to things outside the Microsoft ecosystem. It is too easy to become trapped in the Windows prison.

5 Comments

The low status of software engineers

21/08/2014

A couple weeks ago I read an article by Michael Church titled “How the Other Half Works: an Adventure in the Low Status of Software Engineers“. It is the story of Bill, who had two very different experiences interviewing for two different positions at two different companies: one as a software engineer, and one as a VP-level manager. Bill’s experience is as you would expect from the title. The article is well worth reading.

It was difficult to process the article’s conclusions, because my interview experiences have not been like Bill’s. In fact, in some cases it has been the opposite. I once interviewed for a management-level position that I was woefully unqualified for. Once it was clear I wasn’t the person for the job, they changed the day’s schedule to allow some engineers to unnecessarily hammer me with technical questions. Likewise, I recently interviewed for a software engineer position at a healthcare company with a very small programming team, yet was treated extremely respectfully by everyone, including the CEO. Furthermore, I know I am not guilty of holding software engineers in low status, as anyone I have worked with will tell you.

A few days later, after thinking about the article some more, I started to get some flashbacks*.

I wanted to make changes to scrum teams, consolidating several smaller teams into fewer larger teams. I was told “if we do this, it must be secret. We cannot discuss team composition with developers. They just gossip and act like children.

I was discussing systematic problems with management structure with a sympathetic senior manager. I was told “I once put forward a proposal that employees should choose their own managers. I was laughed out of the room.

We were considering two senior developers for a second Technical Director position. I was told “you must leave this to me to handle, we do not want them to know the other is being considered.” Of course they were good friends, and eventually made the decision themselves.

I raised an objection to a workflow a tools team had put together, concerned it put a large and unnecessary burden on content creators. I was told, “if they don’t want to deal with it, they don’t need to work here.

A team griped frequently about their tools, which were both essential and horrific. Management felt they weren’t sufficiently appreciative when any minor fixes were made. Instead of fixing the tools, they and I were told “there will be no more discussion of these issues, except as initiated by management.

Until now, I thought of these events as incredibly stupid decisions made by unqualified and disconnected individuals. Unfortunately, that’s not the case. These are incredibly predictable decisions made by normal individuals who are produced by a totally unsurprising system. Once the engineers are no longer running the show, they are quick to lose social status. Engineers remaining in management will be assimilated, demoted, or their position removed entirely. There’s no way to reverse this, and I think it’s why culture can so quickly spiral from enjoyable to miserable.

Finally, it’s also interesting to think about this in the context of the Silicon Valley “anti poaching” conspiracy which depressed employee salaries. It demonstrates the systematically low status of software engineers better than anything. Management at Apple, Google, Adobe, Intel, and more, saw engineers as mere pawns, while simultaneously acknowledging how vital they were to the success of those companies. What a world!


* If you’ve worked with me before, you can probably guess who some of these nameless individuals are. I have not obfuscated things for the sake of protecting the innocent, because I don’t find these shitty managers innocent.

1 Comment

A manager’s primary job is to build trust

14/08/2014

While interviewing for my new position at Cozy, I was repeatedly asked what the job of an Engineering Manager is.* By the end of the day, I had decided (for myself, anyway) that the most important job of an Engineering Manager** is building trust.

  • Senior engineers must trust you. They can succeed without you, but you can’t succeed without them. Why does your job exist? It isn’t enough for you to trust them; that’s a prerequisite. If you don’t trust them, that needs to be rectified first. If they do not vehemently trust you, your role is not just worthless, but a net negative.

  • Junior engineers must trust you. They need to have a reason to stick around. They must trust that you are giving them opportunities, and they don’t need to leave to be treated better. They need to trust that they are learning, growing, advancing. Finally, they need to believe that if and when they leave to see what else the world has to offer, they will be welcomed back. If junior engineers do not trust you, they will leave, and take their ideas and passion with them.

  • Design must trust you. They must believe you when you present estimates or assessments from engineers. They must believe that they are getting good information from you, and you aren’t an out of touch middle manager. They must see continuous improvement and engagement from the engineers. They need to trust that you and the engineers are working towards the same goals as they are, with fire and passion. If design does not trust you, you are damaging engineers and company and should just get out of the way.

  • Management must trust you. This is generally an easy one, because if they don’t trust you, they should fix it or remove you.

  • Finally, one that cuts across roles: malcontents and metathinkers must trust you. Many people (especially engineers) just want to avoid politics and are happy to work on on their tasks and not ask questions. As long as you don’t actively screw up, these people will usually trust you. Much more difficult are the critics. They come in all shapes and sizes. It’s not that they need to agree with you, but they do need to trust you. These people often have big ideas and cultural influence. Distrust will drain your organization of talent. As a member of this category, I take this very seriously. When I’ve actively distrusted management, and subsequently left, there’s been a flight of talent afterwards as problems get worse. I’ve written about the importance of the malcontents on this blog before, and as a manager it’s always been a yardstick. If malcontents and metathinkers are leaving, something is going very wrong.

Trust is probably the most important metric for whether you’re doing a good job and your organization is healthy. It is a product of some actions, and a foundation of others. If it’s going up, your organization is getting stronger. If it’s going down, you need to get to work.


* I really enjoy interviews, especially in-person interviews, because it really helps me clarify my beliefs. This can lead to a high bounce-rate, but generally I’m left with culturally compatible companies after that. I consider this a benefit but YMMV.
** Any manager, really.

6 Comments

Portland, here we come!

6/08/2014

Tomorrow, my family leaves on a four day trip to begin a new life in Portland, OR, as the Engineering Manager at real-estate startup www.cozy.co. I am incredibly excited to join the company for all sorts of reasons (the role, product, team, founders, location, pretty much everything). It’ll also allow me to focus on what I’m most passionate about: engineering and development management. So there should be fertile topics for new blog posts, though I suspect the purely engineering or Python-centric posts will get fewer (except for goless, which I plan to maintain).

Now for the heavy stuff. In addition to a new chapter opening, several chapters are finally closing. Since deciding to leave Iceland earlier this year, life has been a depressing adventure. After a promising start at CCP Atlanta, the studio was shut down. This caused us to become homeless. We were 2 days from closing on a house (for which we lost a very large amount of earnest money). So a few days later we drove to Austin and moved in with my in-laws for about 2 months. I found a new job at The Foundry, but I ended up not enjoying working remotely. I was looking for a new job just a few weeks after starting (the job was just for a 3 month contract so they were aware I was looking). We left my in-laws mid-June and moved into their lake house, which I describe as 30 minutes outside of nowhere (over an hour into Austin). We haven’t had running water for weeks due to pump-house problems. My wife and son have gotten cabin fever, unable to make friends with a culture we don’t seem very compatible with. I haven’t been able to give a concise answer to “where I live” or “where I work” since March. Moving costs keep building. My son is behind on his vaccinations due to moving around. It’s been the most difficult time of our lives.

And oh my god is it hot outside.

So here’s to a new job, a new city, a new start. See you on the other side!

10 Comments

Hiring your cake and eating it too

6/06/2014

When evaluating candidates, I have always been a believer that cultural fit and potential to improve is more important than technical ability. Of course I like to review real code samples and give a programming test, but I rarely ask for whiteboard programming. I am not a master of algorithms or math and don’t have a CS background, so I don’t require that of most candidates*. As Five Thirty Eight explains and shows, people just want to date themselves.

This policy is amazingly ego-centric. But it’s also worked pretty well. Without exception, I’m proud of the hires I’ve had a primary stake in. But it is the best policy, at least for the type of work I’m doing?

I think I am a pretty darn good hire. Why would I want to exclude people like me? Well, the fact is that I’m not special. There are way more gifted people around than me. There are plenty of people who are a great fit, and are great leaders, managers, developers, and coaches, and are awesome at math and algorithms. Should I overlook myself to try and get someone better?

Clearly companies like Google can do this. There are anecdotes about people who they hired the second or third time around. People like Steve Yegge. On the other hand, there are plenty of managers that hire “to fill a seat.” Can every company interview like Google, and reject otherwise promising candidates that do not ace a challenging technical interview?

Who you choose to hire does not define what your company is, it defines what your company will become. If you give in and make unenthusiastic hires, your amazing company will be dragged into mediocrity. If you hold the line and hire only the best, you’ll continue to excel, if you can find people. In reality, most companies are somewhere in the middle.

The “best” policy is the one that fits your situation. In an isolated job market, you may choose to value fit and culture. A tight-knit culture may help retention, and make it easier for the inevitable low performers to improve. At a startup, you may have limited headcount, short timelines, and immediate technical needs. Cultural fit would be trumped by technical expertise and experience. On the other hand, cultural fit may be most important at an established company. The biggest risk is a dilution of the culture, and there are plenty of senior people around to do mentoring.

Recognizing what you should select for is much more important than simply always trying to be as selective as possible.


* Obviously there are exceptions. If you need expertise, you need expertise. My thoughts apply to the 80% case.

1 Comment

Adjustable standing desks should be mandatory

26/05/2014

At CCP’s Iceland office, everyone’s desk is able to adjust into a sitting or standing position. I don’t know who decided this perk. It must have been a huge expense. Adjustable sit/stand desks are already expensive in the USA, and in Iceland I’m sure they were three to five times more expensive. Until recently I thought it was required by law! This is quite an investment for each worker, but in my opinion, well worth it for a wide variety of reasons, from health to programming. Why?

  • Lots of people want to try a standing desk but don’t want to be “that guy” who asks for an expensive piece of equipment but doesn’t use it. Having an adjustable desk by default removes barriers to entry.
  • Seeing people stand (and talk about how much better it is) becomes viral. I watched it catch on at work over a few years to where everyone in certain areas is doing it. This wouldn’t have been possible without everyone already having adjustable desks.
  • Standing for part of the day completely fixed my sciatica (lower back/hip/butt pain). It also apparently has lots of other health benefits.

Okay, but “health of your workers” is a pretty nebulous concept, and in America, a business’ job is to make money for shareholders, not, like, improve society! Why would Donald Sterling want to buy black employees adjustable desks in addition to cars and houses?

  • It helped me concentrate. I was able to work faster while standing. Standing is time for working. I don’t know if this is universal, but I certainly didn’t see many people playing games or getting lost in a “YouTube hole” (as a friend puts it) while standing.
  • Pair programming and over-the-shoulder reviews were incredibly more effective while standing, even with people of different heights. Standing, I could pair easily with pretty much anyone, from a good friend to an interviewee. I was able to mentor far more effectively since standing felt like such a more natural way to collaborate.
  • Even if you don’t like pair programming (have you tried pairing while standing?), being able to program and edit code collaboratively during a code review is, IMO, a requirement. Standing code reviews were more effective than sitting. More issues got uncovered and more knowledge was transferred.

How do I know all these things? Well, when I transferred to the Atlanta office, I no longer had an adjustable desk (or a sensible healthcare system, but that’s another matter). Suddenly, reviews with people I was very comfortable with and worked with previously felt rushed and unpleasant. They were done while leaning over (“when can I get my crotch out of this other person’s face“), or sitting together (“oh god we keep brushing knees“).

Pair programming, which is the foundation of the way I mentor (and learn), was basically ineffective. No one programs well at an angle to the monitor, and people mistype constantly if the keyboard is not in a natural spot. It’s difficult to share knowledge or equipment in such an awkward situation.

If you want a vibrant and dynamic engineering culture, standing desks are a must. I view them as fundamental to a programming team as decent workstations and SSDs.


Real studies about adjustable desks are difficult to find. This 538 analysis is promising: http://fivethirtyeight.com/features/i-stand-corrected-about-the-best-kind-of-desk/. Otherwise, it is very easy to find endless anecdotes about the usefulness of adjustable desks. Start with the 538 article’s comments if you don’t know anyone!

5 Comments

Book done, back to blogging

18/05/2014

This morning, I send in my final-est drafts for my book, Practical Maya Programming with Python. This is actually the second time it’s gone to production. The editing process has been, uh, challenging, which resulted in several months of delays.

I’ll post with more information when it’s for sale, but you can pre-order it now!

Anyway, now that the book is out of the way, I can get back to blogging more regularly.

9 Comments