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.
Mike Bland has done a series of articles and presentations about the Apple SSL bug over on his blog. To be frank, it’s pretty much the only good coverage of the bug I’ve seen. He’s submitted an article to the ACM; crossing my fingers it gets printed, because it’s an excellent analysis. I’ve been frustrated it hasn’t gotten more traction.
Mike’s take is that this bug could have easily been caught with simple unit testing. It’s sad this has been so overlooked. We gobble up the explanations that do not force us to confront our bad habits. We can point and laugh at the goto fail (“hahaha, never use goto!”), or just shrug at the merge fail (“we’ve all mistakes merging”). It’s much more difficult to wrestle with the fact that this error- like most- is because we are lazy about duplicating code and writing tests.
I have no problem categorically saying anyone who doesn’t blame the SSL bug on lack of automated testing and engineering rigor is making excuses. Not for Apple but for his or herself.
In December, I spent some time polishing up a new fork of the old PlanetPlanet Python feed aggregator, named Planet Mars: https://github.com/rgalanakis/planet-mars . I chose the name to contrast it with Planet Venus, a successful PlanetPlanet fork. My goal for Planet Mars is to make it as simple as possible, to be the best aggregator for the very common use case. It’s based on my experience running a PlanetPlanet-based river at http://tech-artists.org/planet. That feed has been powered by Planet Mars for the last few months.
The main features are:
- Jinja2 templating, in addition to the original htmltmpl engine. Old templates still work, new templates can use a better language.
- Parallelization of feed updating, so things are many times faster.
- The code is stripped down and much easier to understand and improve.
- Planet Mars can be installed via pip, so instead of having to place your customizations in its package directory, you can pip install the GitHub repo and import it as a module into your own code (you can see the Planet TechArt repo as an example).
- Planet Mars otherwise very similar to PlanetPlanet, making switching to PlanetMars very easy :)
Please take a look and tell me what you think, especially if you are an original Planet user.I’m very open to improvements and suggestions. If there’s any demand, I can put this on PyPI as well.
I’ve been following John’s blog for about 9 months and it is one of my favorite blogs. Poignant, digestable posts, that usually get me thinking. The programming posts are the best around, though the math and statistics posts often go over my head (thankfully there aren’t a ton of those). He seems to read a new book every 3 days so a handful of his posts are just really interesting quotes from those books. He has an honesty and seriousness that is missing in some other bloggers I like (Scott Hanselman), but posts much more regularly and in more digestable chunks than some other bloggers I love (Eric Lippert, Jon Skeet). I’d highly suggest subscribing to John’s blog.
My favorite recent posts:
Adding feeds to Planet Tech Art, it became clear that not everyone studies great bloggers like Scott Hanselman or Dave Winer. Here are some rules:
- Your full name should appear somewhere on your main page. Prominently if you are advertising yourself, but at least somewhere in the footer or header. There were some blogs where even a first name was absolutely nowhere to be found. Unacceptable.
- A link to your feed should be somewhere on your main page. In order of preference- top/top of sidebar, sidebar, bottom. I visited several blogs that did not have an RSS feed anywhere. Again, unacceptable.
- Make your first few works count. Many more people will see an excerpt than read your entire post, make sure the first couple sentences don’t say ‘Sorry I haven’t posted for a while’ or something similar.
- Make sure your name is in your blog feed. Or something to identify you. For Planet, this is taken care of automatically, but subscribe to your own feed and make sure it is recognizable.
- Speaking of subscribing to your own feed- subscribe to your own feed and make sure your posts are formatted in RSS properly. I’ve seen more than a few with missed code samples and other plugin-dependent data.
If you read one long blog article this year, make it this one: Rands in Repose’s Bored People Quit. It is one of the most important blog posts I’ve read in a long time, and right on the money.
If you’ve ever worked a shitty professional job (especially programming), and you know you have, you’ll resonate with what’s written there. I told my last job for well over a year that I was bored and actually tried to quit a number of times, and gave exact action items for how to fix my boredom and what my grievances were. Not that any were ever addressed. And in a place like that, they couldn’t realistically be addressed, with so much riding on such an expensive project- they couldn’t give a shit about almost any individual worker or what I perceive as the long term health of the studio.
Anyway, go read it, and pass it on to your managers!
I’ve talked a bit about my problems with OSS as an outsider. Martijn Faassen wrote a great post about his problems with it from the inside: How to Handle Ideas. It’s an informative, lucid post about improving the ways the open source community receives ideas and criticisms, written by an insider.
Even outside of the open source community, it is useful to read and remember his advice and ideas, as they’re useful ways to handle incoming suggestions and criticisms for any internal project you work on.
Ian Cooper, one of the contributing authors at CodeBetter.com, recently wrote an article called ‘Why CRUD might be what they want, but may not be what they need‘. While this applies mostly to the world of applications, I’ve been saying the same things about tools and pipeline for a while now. The basic argument goes, the people designing/requesting our apps have a history and understanding of the process, and when we build new systems, they ask for optimized versions of that same process. But there are very likely ways we can rethink that legacy process in the context of much better technology and software, and change the experience profoundly for the better. It is our job, as the people who sit between technology and content development, to do that.
And the good news, as always, is that if we fuck up, no one dies.
Go ahead and read the article and see what I mean.
Raymond Chen over at The Old New Thing had a few blog posts recently about debug/release build behavior. I have never figured out why, but it seems an incredibly common standard practice to not run in debug because there are too many errors.
The danger of making the chk build stricter is that nobody will run it: Here, Raymond mentions how a MSFT team didn’t support running its app in debug mode because it broke into the debugger too much. Hey, let’s report errors only when nothing is at stake!: Raymond talks about programming different behavior into debug and release builds- specifically, to crash in debug but swallow in release.
Perhaps because I haven’t been around too long, I just cannot understand how so many otherwise smart people can have such, such bad ideas. And how common this particular issue is.
The issue was especially bad when I was forbidden to use exceptions. I wanted to put in asserts since I wasn’t allowed to use exceptions, except that no one else used the debug build, so when people broke these asserts, they never knew. And then when people’s changes broke some new (and pretty fundamental) asserts, I was told ‘oh, we don’t run in debug.’
Wait, what? You have absolutely no way to ensure valid state, or even keep track of state at all, other than in logs that make debugging far more difficult than it should be (because the problem that should have asserted or crashed will only manifest itself much later and it is unlikely you can determine where the state got messed up by just looking through the log, at least without adding a bunch more logging).
Does your studio do this (not run in debug because there are too many exceptions or asserts)? If so, you may need to smack sense into people. This is a god awful and unforgivable practice when you are using any program- programs with persistent state can corrupt that persistent state, and programs without state can return unexpected results. These sort of decisions are indicative of a myopic or insular culture that is in serious need of a rude exposure and shake up.
I’m on Google+, and it is the FIRST social networking site I’ve ever actively participated in. It seems pretty awesome so far, have I been missing this on Facebook all these years?
Fine me here: https://plus.google.com/u/0/112207898076601628221/posts//p/pub