My last course as a grad student at CMU was Entrepreneurship for Software Engineers, in which teams of students basically worked on startup ideas for one semester, sharing their progress and collecting feedback during each class session and presenting to a small group of VC reps at the end of the term. I worked on a silly little app called InstaPie–which I haven’t touched in months (mainly because I don’t have an Apple computer anymore!), though I do plan to pick it back up soon, I swear—and I remember during my presentation to the VCs, one of them asked, “What problem are you trying to solve here?”
This wasn’t my first exposure to the question, of course. We’d been taught to always keep this question in our crosshairs, to not lose sight of the goal. Identifying the problem and proposing a solution is an important part of any elevator pitch, I hear. If you can’t answer that question, then you’ve lost your way somehow. Start retracing your steps until you get back to the place where...
Most of us in software (and probably in other fields) know about hero culture. It’s a concept everybody loves to hate. The term refers to an environment where individuals work in isolation and thrive on receiving sole credit for their work. This is generally perceived as leading to inflated egos and poor cooperation among developers. It’s the same phenomenon you see in professional sports, when star athletes are sometimes accused of not being good “team players” and getting greedy with the ball, wanting to be the center of attention.
So there are social reasons to dislike hero culture. There are plenty of practical reasons, too. One involves a principle known as the bus factor: the more you rely on a hero, the more vulnerable you are in the event of losing him or her—e.g., if he or she is hit by a bus, or leaves for another company.
But you guys know me. If everybody else is going left, I’m going to go right (a highly predictable trait that my friend Sameer frequently reminds me of...
Looking back on some of my recent posts on this blog, I’m a bit annoyed at myself for being too hand-wavy and not saying anything all that original.
I’d like to make an effort, at least in my next few posts, to get more concrete and challenge some of the conventions I’ve observed in the software world. I’ll start with an idea that I think is not all that radical, though it would mark a sigificant departure for most teams I’ve worked on.
How we think about priority
The way most teams prioritize work seems totally sensible on the surface. Essentially, tasks are assigned some priority ranking such as “high”, “medium” or “low”; and then the highest-ranked tasks actually get assigned to people. In a perfect world this would mean that the most important things always get done, and then when there’s a surplus of time a team can “catch up” on issues that aren’t quite as urgent. In practice I think a different reality tends to emerge.
On projects I’ve been a part of, inevitably it turns...
I bet you weren’t expecting any sane developer to make this argument!
Well, to be fair, the title of this post is somewhat intentionally provocative1. But anyway, you’re here now; so it served its purpose. And make no mistake: I am going to defend global state—just possibly not in quite the way you might be expecting.
What we mean by global state
First, some background. If you’re reading this, there’s a good chance you’re a developer so I probably don’t have to explain this; but I think there are at least two forms of global state that come to mind in software. One form is global variables–values that are accessible and can be changed, globally, anywhere, by all of the code in a project. The other is constants–values that may be accessible to potentially every part of a program, but cannot be changed.
These aren’t the only kinds of global state, though. I would argue that globality–apparently that’s actually a word2–is a continuous (as opposed to discrete or binary) property. Meaning...
I never actually worked in an environment like this, but I’ve read enough articles on The Daily WTF to have an image in my head of the old dusty, temperamental servers that companies used to have back in the 90s and early 2000s.
Those were dark days, from what I hear—when your business was victimized at the whim of an unpredictable piece of hardware. If the power went out, or the CPU overheated, or the hard drive failed, your site went down. It was as simple as that.
We live in a different era now, with PaaS and IaaS and all that cloudy good stuff. Your average tech-savvy business owner is going to know there’s no particularly good reason to run your own server anymore if you’re a small company. And if you’re one of the large companies providing these services like Amazon or Google, you have been on top of the hardware problem for a long time, with data centers distributed around the country (or the world) connected in a controllable and reliable way. It’s not an issue...
A few years ago my parents gave me and my wife this knife as a Christmas present:
We weren’t quite sure what to make of it at first, but it wasn’t long before we both loved it. It is a very sharp knife, which makes it a breeze to cut through just about anything. Unfortunately, that anything includes human flesh. I know this because a few months after receiving the knife I was cutting an avocado and the knife slipped in my hand. It was quite a bad cut.
Obviously—I still have all ten fingers—my wound healed eventually. But I do have a pretty clear memory of the incident, which makes me quite fearful of repeating it. Here are two ways I could protect myself from future self-inflicted injury:
Decide the knife is too sharp. I could replace the Shun knife with a duller one, so that if my hand ever slips while cutting again the injury won’t be so bad.
Decide I wasn’t careful enough. In the future I could cut more slowly and be very cautious whenever I’m using...
In a footnote to my post a while ago on SafeYAML1, I established a goal of writing more about my many open source projects, which I have a bad habit of not telling anyone about—sometimes even long after they’re finished!
Here, I’ll give you an example (note: this is probably not going to display properly for those of you on RSS readers; visit the website to see what I’m trying to show you!):
<tableclass="render-to-bar-chart"><tr><th>Method of rendering a chart</th><th>How easy it is (scale from 1 to 10)</th></tr><tr><td>Using Highcharts directly</td><td>3</td></tr><tr><td>Using HighTables</td><td>10</td></tr></table>
Most people outside of the software development profession (and even many on the inside) may not realize that there is some disagreement within the community as to whether or not software development is a form of engineering.
Let’s say you placed software developers along a spectrum, where at one end “engineering” might as well be a foreign word, and at the other end writing software is obviously a form of engineering, in much the same way that painting or sculpture is obviously a form of art.
Personally, I have worked at various points along this spectrum. My first developer job was at a trading company in Philadelphia, which would have fallen pretty close to the extreme left end. At ThoughtWorks I would say the culture was somewhere in the middle, with plenty of developers leaning in both directions (I definitely worked with self-professed “engineers” at ThoughtWorks, as well as individuals who vehemently rejected the label).
When my wife and I moved from Philadelphia to San Francisco in 2010, we brought our espresso machine with us.
Back in Philly, we’d had a modest kitchen with just enough counter space for the machine. On lazy weekend mornings, I’d often turn it on and prepare us each a latte drink. It was a nice little ritual.
So we brought it to San Francisco with us. But our first apartment, a little studio we rented from a friend of a friend, didn’t have the room for it. So the machine went into storage.
Then in 2011, we moved to our current apartment in the Mission. The espresso machine is back; but we don’t have quite the counter space that we did in Philadelphia, so it’s sitting on a little cart underneath our microwave, unplugged.
This isn’t terribly inconvenient. To use it, I only need to pick it up and set it somewhere—say, on our table—then put it back when I’m finished. Still, the fact remains: I haven’t used it once1 since moving here.