(Note: I’m not sure “serious” is the right word for what I mean here. As I was writing this, I overheard a random passerby say to someone, “that’s unprofessional!” Perhaps “professional” is a better word for it.)
While working on some code for my MIT Mystery Hunt team, I started thinking about sorting projects by importance (i.e how bad the consequences would be if they broke.)
The code I’m working on is kind of important, since if it breaks it will impair the team’s ability to work on puzzles. But it won’t totally prevent progress (just make it harder to track it), and it’s not like puzzles are a life-or-death issue. So it’s a bit important, but not that important.
It’s also possible to write code at Google that isn’t that important—for example, a side project with no external users and few internal ones. But even unimportant code at Google is typically “serious”. By that I mean… I guess that it does things “properly” and incurs all the overhead involved?
Code in source control is more “serious” than code not in source control. (I don’t even write hobby projects outside source control anymore, and haven’t really for years—that level of seriousness is table stakes now.) Code running in the cloud is more “serious” than code running on my desktop machine—it’s more effort to deploy, but it’s less likely to suffer from a power outage or an ISP failure.
And it’s also more possible to collaborate on “serious” projects—writing your own web framework can genuinely get you advantages over using an existing one, but collaborating with others will be a lot harder.
Of course, if your project is important but not “serious”, you have a big problem. You need it to keep working, but it’s running on your laptop, using an undocumented framework only you know how to work with, using your personal Amazon credentials, and you do most of your testing in production. Sooner or later, your important project will break, and it will suck. (And if you do manage to keep it going, this will sometimes require a heroic effort.)
On the other hand, the costs of being too “serious” are all about overhead. You have a perfectly good computer on your desk, but you pay for two servers in the cloud anyway, one to deploy and one to test on. You have separate project accounts on various services, separate from your personal ones, and manage lots of extra credentials. (And you don’t store them on your laptop, oh no; you store them in a credential storage service. Er, hm...)
“Don’t test in production” is good advice for important projects, but it’s defining advice for serious projects—if you don’t follow it, that’s inherently less serious than if you do. Your overhead is lower, but with a higher chance of catastrophe.
This musing brought to you by the entire day I have wasted today, trying to get a local development environment to match the behavior of a cloud environment, to reproduce a problem. I haven’t succeeded yet. The seriousness of this overhead really feels out of proportion to the project’s importance—it’s not even mystery hunt season, nobody’s even using it! Yet I would feel unserious leaving a trail of pushes to prod to diagnose the issue, without at least visibly struggling to do it “the right way” first.
(This also belatedly explains a number of annoyed disagreements I have had with other devs over project infrastructure. I each case, I was annoyed that their choices either seemed too serious—having excessive overhead—or else not serious enough.)
Importance vs Seriousness of projects
(Note: I’m not sure “serious” is the right word for what I mean here. As I was writing this, I overheard a random passerby say to someone, “that’s unprofessional!” Perhaps “professional” is a better word for it.)
While working on some code for my MIT Mystery Hunt team, I started thinking about sorting projects by importance (i.e how bad the consequences would be if they broke.)
The code I’m working on is kind of important, since if it breaks it will impair the team’s ability to work on puzzles. But it won’t totally prevent progress (just make it harder to track it), and it’s not like puzzles are a life-or-death issue. So it’s a bit important, but not that important.
It’s also possible to write code at Google that isn’t that important—for example, a side project with no external users and few internal ones. But even unimportant code at Google is typically “serious”. By that I mean… I guess that it does things “properly” and incurs all the overhead involved?
Code in source control is more “serious” than code not in source control. (I don’t even write hobby projects outside source control anymore, and haven’t really for years—that level of seriousness is table stakes now.) Code running in the cloud is more “serious” than code running on my desktop machine—it’s more effort to deploy, but it’s less likely to suffer from a power outage or an ISP failure.
And it’s also more possible to collaborate on “serious” projects—writing your own web framework can genuinely get you advantages over using an existing one, but collaborating with others will be a lot harder.
Of course, if your project is important but not “serious”, you have a big problem. You need it to keep working, but it’s running on your laptop, using an undocumented framework only you know how to work with, using your personal Amazon credentials, and you do most of your testing in production. Sooner or later, your important project will break, and it will suck. (And if you do manage to keep it going, this will sometimes require a heroic effort.)
On the other hand, the costs of being too “serious” are all about overhead. You have a perfectly good computer on your desk, but you pay for two servers in the cloud anyway, one to deploy and one to test on. You have separate project accounts on various services, separate from your personal ones, and manage lots of extra credentials. (And you don’t store them on your laptop, oh no; you store them in a credential storage service. Er, hm...)
“Don’t test in production” is good advice for important projects, but it’s defining advice for serious projects—if you don’t follow it, that’s inherently less serious than if you do. Your overhead is lower, but with a higher chance of catastrophe.
This musing brought to you by the entire day I have wasted today, trying to get a local development environment to match the behavior of a cloud environment, to reproduce a problem. I haven’t succeeded yet. The seriousness of this overhead really feels out of proportion to the project’s importance—it’s not even mystery hunt season, nobody’s even using it! Yet I would feel unserious leaving a trail of pushes to prod to diagnose the issue, without at least visibly struggling to do it “the right way” first.
(This also belatedly explains a number of annoyed disagreements I have had with other devs over project infrastructure. I each case, I was annoyed that their choices either seemed too serious—having excessive overhead—or else not serious enough.)