Do “Shitty” Work
ryanhoover.me
Do “Shitty” Work
1–10 of 30 posts
Re: Do “Shitty” Work
#2What's the most important thing on your to do list today?
Re: Do “Shitty” Work
#3What's the most important thing on your to do list today?
Fix huge bug that everyone else refuses to deal with.
Re: Do “Shitty” Work
#4This really echoes with me - I see too many startups focusing on the wrong things or more importantly forgetting that they need to do everything...
1) You still have to do the things that you're bad at
You're a developer/designer/architect/[insert profession] so that's what you do. You build great apps or you design beautiful pixels. That's probably what people have paid you to do and that's also what you're good at. It's also highly likely that you enjoy it. The problem is that you focus too hard on what you can do and not on things you can't do. This means that you launch products that are half-baked. Most people launch without focus on customers or marketing but sometimes it's a lack of focus on design or user interaction. The point here is that you need to start looking at things that you don't enjoy because that's probably the area that needs the most attention. Now, this doesn't mean you have to learn how to be something you're not. You can outsource it, hire someone, partner with someone... but you do need to do it if you want to be successful.
2) Do the unscalable things
This is of course copied from pg's essay [1] but it is so relevant to startups. Early in the life of a startup, you need to make sure you have excellent customer service and a thirst for growth. 'Moving the needle' is what counts - you need to do it quickly. When you're bootstrapping this can often mean cold calling or 'shoe leather'. Many first-timers brush this aside as 'old marketing' and 'it'll never work'. It does work. However, it's hard work. Focus on the things that move the needle early on, however troublesome and manual, because you then you will learn what's important enough to build. You can then automate much of what you already know and move on to the next challenge.
Re: Do “Shitty” Work
#5What's the most important thing on your to do list today?
further validate ideas found while talking to business owners in my niche, also setup a time to talk to a competitor in my niche that offered to share pains and problems common in my niche that he's found over the years. Lastly, respond to emails from several business owners in my niche who were willing to talk about their pains and problems...and where I can provide a software solution to them. Notice there is no wireframing, code writing, blog posts, etc etc in my todo list. Until I have 5-10 prepaid customers...I'm not touching my code editor.
Re: Do “Shitty” Work
#6Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
Re: Do “Shitty” Work
#7Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
I think it depends on how you define code quality. If you mean it's been re-factored (for example) as much as possible, then I agree. . .you are just polishing the apple. But if you mean acceptably (to the customer) bug-free, then I think your work was worth it.
Re: Do “Shitty” Work
#8This is a great post, and it's a good illustration of the difference between fun hacking/project buildling, and actually creating a business around software.
The ugly fact is, when you're creating a startup, only about 5% of your time is spent on the fun coding stuff, the main implementation of your whole idea.
The other 95% is spent on "plumbing" -- refactoring, credit-card integration, e-mail newsletters, browser bugs, server administration, and so on. And that's even before you get to things like hiring, fund-raising, and such.
Re: Do “Shitty” Work
#9Something I learned over the years... if your code quality is too high, it means you're sacrificing productivity.
I couldn't disagree with this sentiment more.
Of course, it depends on your definition of quality, but for the sake of argument I'm assuming that we're including things like test coverage, code complexity, code cleanliness/readability, structural soundness (cohesion over coupling, the single reponsibility principle etc) and so on.
The point with all of these things is that as much as they might seem to be a waste of time when people can be hacking on something else, they (imho) save orders of magnitude more time than that in terms of maintenance of a codebase: being able to quickly fix issues as they occur; how quickly new developers can grok the codebase; how easy it is to add new features that were not part of the original design.
Unfortunately I have no hard data to back that opinion up, but it is what I intuitively believe to be true based on experiences.
Re: Do “Shitty” Work
#10What's the most important thing on your to do list today?
Visit toilet after dinner.