In many respects my side-project engagement with Bagrace epitomizes the startup experience we all love reading about so much. This is as real as it gets, folks.
What can it be compared to besides wearing multiple hats? How about operating a stove with 20 burners, drinking from a firehose, and typing with your left foot all at the same time.
The span of one person’s reach in a small enterprise just boggles the mind. Here is a list of what’s been on my plate over the last week, just to give you a taste of the kind of wild ride it is…
When I started this blog over three years ago, it was my personal goal to blog at least once a week. It wasn’t for the shortage of things to say that I needed to space out my posts, it was because of the lack of sleep and excess of enthusiasm for the little project I was working on at the time – justliked (now RIP) – that I couldn’t find time to blog more often.
Even through the good stretches here I never hit my self-imposed once-per-week target. It was more like once every two weeks. Now it’s more like once a month, if that. It’s naturally to feel anxious about those times, and I have been in that boat far too many times.
If you are not “present” for a few weeks, the world still goes on without you. Just remember that you are always justified in fulfilling the most important thing obligation first, even if it’s not writing.
Last year, about 2 years into blogging, I finally managed to get my proverbial big break with The one interview question I always ask, a post that went viral and still drives about 80% of the traffic to this blog. You should read it. It’s really good.
Anyways, as hits tend to do, it got me too wrapped up in chasing that next big one, and the quality of writing suffered as a result. I wasn’t as passionate and direct about the subjects I wrote about, and it showed. If you watch the numbers, things can get pretty depressing. Sitting down and writing becomes an effort to convince yourself that the next post will be different. That is if you write for the numbers.
What I learned is that if you don’t write for the numbers, then you are free to be happy about every piece of your writing, not just those that do well.
Truth is I have just as much that I want to write about as before, but this time around my free time (actually the remainder of my mental energy that can be used for blogging) has been sapped by Bagrace, which I am insanely excited to be working on. I still have a little free time left, but little will to use it for blogging – an understandable weakness.
All of this is to say: I’ll be back. :)
With the year barely under way there are already plenty of news to start it off right. Let’s hope this is just a taste of what’s to come, and that it actually tastes good! Continue reading
Note: I am in NYC, and I am fine. I wrote this before Sandy came to town and couldn’t post it until now.
Here is a confession. I’ve never been entirely comfortable asking others for help. I know, I know I am not the only person who feels this way. After all, to ask is to obligate someone to answer. And feeling obligated to respond is the last think I would want other people to feel.
For the longest time this has been my modus operandi, even though in my heart of hearts I understood that this position was silly and untenable. Now I think I am finally free of these notions, and I want to share what got it out of my system. Continue reading
One of my constant struggles in managing software products has been in establishing and keeping tabs on the correspondence between the amount of work completed on a project and the quality of the software produced.
Oddly enough the main claim on time that would otherwise be spent on “designing quality” is spent on developing features, which, unlikely quality, are easily counted and plotted against costs. Shipping features often gets you off the hook quickly because you can easily explain a feature. Quality, on the other hand, eludes a snappy description.
All this is fine until one must negotiate something out of the product. Negotiating on a feature is usually a minor inconvenience, but when negotiating on quality the conversations get tougher and less pleasant. Customers leave, teams are demoralized, and product management is dismayed.
Why then do we still rally behind the feature list every single time? Here is why and what to do to rebalance the equation… (or skip to TL;DR section below)
One Algae to go, please.
Creating Algae has been a tremendously rewarding experience. I started on it because, having worked on Turn-O-Phrase and LinkPeelr, I have grown very fond of Google App Engine but very weary of re-inventing the boilerplate from scratch every time. I hesitated to jump to a brand new project knowing that the first couple of days (that’s couple of weeks for us weekend warriors) would be spent copy pasting and adjusting defaults.
I started working on Algae in March, and back then it was primarily about scratching my own itch. Since then, I got to thinking that there might be others, constrained by time, and frustrated by the lack of subjectively good boilerplates for Google App Engine, who hunger for a saner and smoother start to their Python projects.
At that point I started thinking of Algae as something that coule benefit the community at large. I even went so far as to create a Skillshare course around it, but that’s another story. Continue reading
Last weekend I had the pleasure of attending first ever eCommerce Hack Day. I posted recently about my prior hackathon experience, and this time I decided to heed my own advice and do things right. Spoiler alert: I still walked away without any prizes, but it was altogether a more positive and rewarding experience.
Oh, and if you just want to see what was built, go ahead and check out CraftEconomy.
I love magic code. It’s both a sign of a rapidly evolving software where priorities are fluid and sometimes moving on is the only option, and a rapidly evolving organization where code ownership tends to switch and new owners tend to write around things, leaving magic code at the margins of the codebase.
Magic code is sometimes a testament to poor or non-existing code review and documentation practice. Someone wrote it, then they left. Then this other person came in and tried to untangle it, and all we got was a broken build and we haven’t touched it since — no time and no energy to understand it, if leaving it intact gets the job done.
Magic code is scary, especially when it resides at the bottom or at the heart of your software stack. This magic code is always guarded by select few who know of it’s central nature in the world, but can’t explain how it makes the system work, which gives rise to a kind of religious following. We know it’s important, we know it rules over us, but we can’t tell you how it functions or why it works they way it works, and… we are afraid to challenge it.
Absence of magic code can be scary too! That’s the opposite problem. When everything is neat and proper, when everything makes sense, when there is no unexplained, preternatural totem to worship and obey. This is usually a sign that too much time is spent preening the code base, fixing the technical debt, and doing so obsessively, refactoring and generally making things perfect for the sake of perfection.
Neither extreme is good, and both are equally unrealistic. As is often the case with matters with two extremities, it’s all about the balance.
Does your code base have magic code?
I’ve just gotten past a peak interviewing period where I would interview 3-5 engineering and product management candidates every week. I’ve used this question for as long as I’ve interviewed people, and it has never failed to reveal something not-immediately-on-the-surface about every single candidate. So I was not surprised that it still works, but I did get a little better at understanding why. Continue reading