I’m working on an app right now. I’ve been working on it since I escaped my gilded cage, modulo distractions – consulting, travel, talks, writing. It’s fun, working on my idea, and thankfully I met a great designer so it’s not going to be Developer Art. And it’s cool. I’ve had a working demo for a while which people have seemed to like, and now just refining the UX and some horrible bug (relating, I think, to filetypes) remain.
Of course that last 20% takes 80% of the time again. And I’d been making progress, knocking out all the small things, in between running around, but then I got 8 days to focus on it almost exclusively and discovered that past-Cate had left future-Cate, now present-Cate, a bunch of tedious and time-consuming things to do, and also that horrible file-type bug. And present-Cate understood what past-Cate had decided, but that was when being the entire dev team got a little lonely.
It had been really nice, making all the decisions, not having to do code-reviews, or spend time justifying decisions I’d made, because someone else would have made a different choice. I believe in code-review as a process, but so much tech-bro-male-dominance gets played out in them. Some people (men, I find) seem to view it as a making you jump through the hoop, where the hoop is “how I would have done it” and deviations must be justified. “Suggestions”, which seem a lot like orders, which I would resent much less if they worked most, or even half, of the time.
Naturally, it’s easier to live without code review on a platform I’m already pretty expert in, and I expect it will be harder when I move on to Android, where I haven’t already architected and led an app from first check in through to launch.
Really, there are two things I find hard about being the entire dev team.
Firstly, if I’m out for whatever reason – sick? The one day a week I force myself to take away from the computer? Meetings? A deadline for some other project? That’s it, nothing moves forward. It makes it easier to give up on progress that day, because it feels like it’s not going to move the needle anyway. On a team, if I took a day sick, I might still do code reviews for other people, or check in some little things, if I felt a bit better later in the day.
Secondly, when deciding between two alternatives, like the one where the mocks have arrived and that library component won’t do quite what it needs to and should be ripped out and replaced with a custom one, I’m the only person with the context. I think the decision is pretty clear, but I need to talk myself into it and convince myself that I haven’t missed anything. There’s no-one else with that context to have that conversation with. Thankfully a friend with some context, who was nice enough to listen and tell me I was right, but I missed sitting next to someone and being like, argh, you saw these same mocks and you code reviewed that code already and now it needs to change and yes.
I still have no-one to talk to about the filetype bug, but that’s OK. I’ll write more unit tests to understand it. And maybe start talking to myself. Or my plastic ducky.
Not knowing what it is. Rejecting it as silly without giving it a try. A good try, as there is a learning curve. It will slow you down at first. If you give up before the payoff then you will say “oh that was stupid”.
UI and Networking. On iOS most of what we do is UI and networking, rules out 90% of app, so not really useful.
EBay Fashion app. All test driven.
3 Types of Unit test:
Return value test
State test
Interaction test
Patterns of testing. The Design Patterns book, the Gang of Four never intended it to be the beginning and end of design patterns.
Not going to be rocket since. About getting through the barrier. Writing unit tests after if necessary, but ideally before.
Return Value Test:
Arrange: set up object.
Act: Call method that returns a value.
Assert: Compare against expected value.
With this alone, you should be able to get a very far distance. Onboarding engineers at Facebook, teach them not to be shy about extracting stand alone functions. Helps overcome that barrier.
State test:
Arrange: Set up object.
Act: Call method.
Assert: Compare against expected value.
Since interested in a side effect, just need an additional call to verify state. Should be able to write quite a few tests with these two techniques.
Interaction Test:
Don’t need to be isolated units. They can be connected, as long as they are fast. Check that the system under test (SUT) is communicating correctly to something else.
Don’t want to talk to the real thing:
Takes too long.
Might not be there.
May not have everything (don’t want to use things up).
Might want to test the failure (normal end to end tests).
Want a fake thing that the test can control. Need dependency injection, if the middle thing is creating the end thing, it’s hard to test.
Dependency Injection:
Extract and Override.
Method injection.
Property injection.
Constructor injection.
Difference between having a singleton, and a single way to access a singleton. E.g. NSUserDefaults. Don’t want to access it in this way.
TDD was working for me in a greenfield project, but how many of us get to stay in such a place?
Seams
Make a cut – subclass, override “userDefaults”, do what you want. Very powerful. Very effective with legacy code. Very dangerous. Like a drug. But will end up with the bane of testing code, fragile tests, because tests are coupled to implementation.
For getting started, especially with legacy code – good technique.
Method Injection
Better for other things, like calling “[NSDate date]” – will cause havoc with tests. Can swizzle, or just pass in what time you want. Now you will have a method that does more, now it’s tied to any time, not the current time. Helpful as context for injected object is very small. When spans across method, probably want to hang on to it as a property.
Test can inject the fake thing. But what about production code? Can end up with nil. Objective C will be like “whatever”.
Create custom getter with lazy eval. If no value, get the default value.
Inject in constructor – workhorse of dependency injection. Biggest benefit, makes everything explicit.
Can be annoying to have everything explicit. Long chain of dependencies is a code smell – you have too many dependencies.
Even then, you can simplify that, by using a Builder. Builder pattern creates the object you want according to however it is set. Set in any order, or not set and have it have defaults.
Constructor injection is the main one.
Ambient Context. Change something globally. Swizzling is an example of this. You can, sometimes helpful. But dangerous. Have to have your test restore the pre-test condition.
Let’s learn some good things from other people in other disciplines. There are plenty of smart people who are not using Obj-C
Interaction Test
Types of Fakes: The Art of Unit Testing
Stub: Fake that provides a pre-canned answer.
Mock: Recording how it is called by the SUT, so that it can assert.
Difference is which way the test is pointing to make it’s assertion.
Don’t need a DI framework in order to do DI as a concept.
Mocking, if never mocked before don’t use OCMock or OCMockito at first. Use them eventually. Meanwhile, you can make your own fake. Subclass and override all methods. Test Driven iOS development, means don’t have to do that in Obj-C. Dynamic language, supports DuckTyping.
Subclass NSObject. Put the method in. Use a simple property to record the number of calls. Have a fake return value (if unspecified is nil). Capture arguments.
Interesting thing about doing by hand, answers question of “what do we do in swift”. No introspection available to us. Do it by hand, laborious, might cry a little bit, but nothing stopping us.
Now we have a mock, use it. Start writing some tests.
Saw woman texting with a T9 phone. Stopped, looked, made sure he saw what he really saw.
Presenting from a phone. First presentation, used a projector. Amazing how far we have come.
Generally known as an opinionated person. Don’t speak in wishy washy words, very boolean. Either believe or don’t believe. If not, just shut up.
In career get feedback, “brash”, etc.
One thing is claiming he has a dysfunction called “not invented here”. Yelled at for wanting to write things himself, not wanting to use other people’s solutions.
Think it’s a problem, being egotistical. Thinking he’s better than everyone else.
In own introspection. Am I really this evil person? Do I need to fix this? Realised no, really don’t. Positive side.
Why he doesn’t like other people’s code. Why he doesn’t like 3rd party frameworks.
Lot of reasons. One that it is not, code quality.
Code quality is a complex subject, not going to put it on one side. Talk on it’s own, if could even fit in a talk.
“All code sucks, eventually. All code suffers from bit rot, no matter what.”
Three points:
Reinventing the wheel.
Becoming a better developer.
Code ownership and maintenance.
Reinventing the Wheel
As an engineer, write a lot of networking code, persistence code.
Whenever start a new project, start from zero. Don’t have a cheat sheet, or a code snippet, or a template.
Write it each time not because like torturing himself, because he knows can write it better. Smarter today than yesterday, especially than three months ago.
Shouldn’t be reinventing the wheel, but iterating the wheel is something that we should be doing. That is what we are really doing when we do that code over again.
Becoming a Better Developer
“Any insufficiently understood technology is indistinguishable from magic.”
Think something is hard, never bother to go out and look. By writing it yourself, disperse the magic. In it’s place you have code you understand.
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
Code Ownership and Maintenance
Even though write it today, no guarantee can read it tomorrow. A year from now it’s going to be complete garbage. When write it today, want to be able to read it in a month.
Risk management with Apple (they change things all the time).
3rd party framework is like introducing to an unmonitored team member.
No guarantee of updates.
No guarantee of quality or direction.
Risk of App Store rejections.
Happy Medium
There is good code out there.
Manage your risk: reward needs to justify the risk.
Consume the code, own the code, make it yours.
Learn the underlying technology before adopting a framework.
I’ve rejected a number of posts for today, because I worry that whatever comes next will be taken in the context of this. Because today is a day where the schedule says, write about women, and I think, I should write something positive. And there is so little positive to say about women in tech. The data is bad. The numbers are going down. I got nothing.
And then, I had a conversation with a fabulous woman about shoes. I’m at a tech conference right now, and I’d been feeling slightly out of place. Since I sat on the train and didn’t manage to make conversation. Compounded by walking up a hill in heels and getting left behind, which felt like something of a metaphor.
And then we talked about shoes. Because to be honest, that is my metric for a good tech conference. I meet another woman and we have a conversation about something else entirely. And I talked to other people, had good conversations, made good connections.
Had something of a heart to heart, in the way that you occasionally do as a blogger. When you discover someone and find that you have read some of their writing, and they have read some of yours. And this was notable for me, because I was having this conversation with a dude.
Honestly my network is probably quite dude-lite, considering I work in the tech industry. I meet a lot, but I rarely have such open conversations with them.
I said, thinking I was revealing a terrible secret, that I worry sometimes that I’m less good than I used to be. And he said he felt the same, but that he thought it was normal.
Imagine, my dark secret, normal.
In the tech industry, we talk a lot about the impostor syndrome. But almost as a matter of pride, like, wow, it’s so incredible that we, such clearly brilliant people, sometimes… question our brilliance. That surrounded by other brilliant people we sometimes… feel a little inadequate.
But then when we feel like that, we stop feeling like that and go and be awesome instead.
Thinking about it, a great day’s programming, is when you get a week’s worth of work done in a matter of hours. But a bad week’s programming, is when work that shouldn’t even exist (because you screwed up) takes all week.
This is what makes it addicting. The high highs, the low lows. The unpredictable reward. So we’re probably all having low points on a pretty regular basis (and they last longer than the highs).
Meanwhile, I’ll try and stop feeling inadequate about feeling inadequate… and go and have an awesome time, instead.
One of my friends sent me a grammatical suggestion on something I had written. I assumed he was right, made the edit, but then that looked wrong too, so I looked it up. Discovered they were both fine, but the way I had it was slightly preferred. Sent him the link, without that explanation, because it seemed redundant.
Offended him, because I had inadvertently played into the thing that we do in tech, the petty one-upmanship, and the assumed superiority. Realised, as soon as he called me on it. But was shocked, because I had no concept that dudes do that to each other, too.
I realise, how blinkered that sounds. But as I work so hard to balance my own environment, even if the wider one is completely out of whack, I see and hear these things happening to other women, as they happen to me, and miss them happening to dudes.
Added factor, with dudes it’s less likely to induce massive stereotype threat, so maybe they don’t feel the need to mention it.
How much time do we spend arguing about stupid shit? The Heartbleed vulnerability was checked into an Open Source project in December 2011, and to name one example, how many examples of huge arguments about de-gendering Open Source Project language have I seen in that time? Instead of, ooh, I don’t know, a unit test?
(Note: I’m not saying the change to de-gender language is stupid, but the argument about it is. OSS competes for the rarest commodity – time – alienating large segments of the population can hardly help with that. These arguments typically centre around rejecting a patch.)
Or, variable naming, file structure, ordering of cases in if statements. All these things that it’s so easy to have an opinion on, because above some low bar it doesn’t matter.
Bikeshedding. Trivial arguments and intellectual pissing contests. Why, if every minor decision needs to be justified to half a dozen people, do we even bother having multiple people on a project? More time spent arguing over trivialities than actually getting shit done. At best tangentially relevant information is introduced, not because it might be interesting, or helpful but to demonstrate the towering intellect of the author.
Except, does it? How is it smart to waste time on this stupid shit? I’ve never understood arguments about style guides for example, or the benefit of 80 vs 100 character line lengths. The whole point, I thought, is to not have to think, or worse, debate this stuff. Pick something. Stick with it. It’s fine. It doesn’t really matter.
I’m pretty sure no-one ever encountered an argument on file structure that was so utterly brilliant, they thought, “wow s/he must be an amazing programmer!”.
There are many things that I find tiresome about the tech industry, but this must be… ooh, top five.
I go to a startup event, and it’s interesting to hear non-technical people talking about developers like over-priced commodities.
L comes to me for advice, she’s contemplating her next move and worrying about whether or not she feels passion for the project.
C reads my blog, tells me that she can tell I’m passionate about writing from my writing. I say, “that doesn’t mean I want writing to be my job.”
R knows what she wants to prioritise with her career, but is hearing conflicting advice about what she should prioritise instead (and it sounds a lot like “passion”).
I loathe the word “passion”. I loathe it in relationships, where it seems to mean seeking out the movie style ending rather than the day to day. And I especially loathe it in career advice. I like the Study Hacks ethos – it’s not passion, it’s hard focus.
Entrepreneurs talk about passion. Cool. You probably have to be chasing something really hard to give up economic stability. That doesn’t mean it’s for everybody.
Passion is Blinding
To be passionate about something, means being unable to look at it rationally. This is unfortunate, because rationality is a very important part of building things well. Maybe it helps you stay awake for a week on a caffeine-fuelled coding binge. But it’s hard to love anything that much, for long.
Passion doesn’t help you prioritise, it asks you to do everything. Data and pragmatism help you to prioritise.
Passion doesn’t help you weigh up the eng-overhead and the data on usage of that feature and advocate for cutting it.
You are Not the Decider
There’s a reason why Product (PM) and Engineering are two separate roles. The PM looks at the big picture and the whole product and market (the what), the engineer owns how to build it (the how). It’s cool to have an opinion, but the PM is the decider on the what (this is fair! Engineers don’t like it when PMs try to be deciders on the how).
When you feel passionately about the what, but you disagree with your PM and they overrule you? That sucks. But that is their job.
You might think you know better, and maybe you have a really bad PM and that is true. But if you have a competent PM, they are going to make better decisions than you (on average) because that is how they spend their time.
Competition is Fierce
A friend was working on a super cool project, that she should totally have loved… but she didn’t. She should have been really happy… but she wasn’t. She was really stressed by the environment.
We talked about it, and I observed something along the lines that it wasn’t that I didn’t want to work on something like that, but that I really didn’t want to work with the people who really wanted to work on something like that.
Because a lot of people go looking for passion, and The New Shiny, the people who end up building The New Shiny are often the people who were willing to shove other people out of the way to get there. If you are happy to go about your work looking over your shoulder to see who might push you out of the way to get what they want, cool. I’m not.
You Live in the Details
It’s great to like the bigger thing that you are working on, but at the end of the day engineers mostly spend their time pushing pixels or protos. 1000 lines of test code does not make me feel warm and fuzzy about the product; it makes me feel confident about it’s stability. The menu bar might be part of some grand vision, but after a couple of days of just you and the menu bar, the vision seems pretty far away.
If Not Passion, Then What?
As a developer, passion is a distraction. For me, it’s not about passion for a product, it’s about having a healthy relationship with my job, a commitment to my career, and then maybe a general excitement about technology.
What does a healthy relationship look like?
I like what I’m working on, and I think people will be better off because it exists.
The people I work with treat me with respect.
My work does not have to encompass my entire life. I can maintain other interests.
Most importantly though, it’s good if you think that leadership can manage and ship a project of this scope (preferably, this should be based on evidence) and that you can manage and execute on the part of the project within your scope (again, it’s best if this is based on evidence).
I say with evidence because passion hides, rather than cures mismanagement. Passion is the advocate of scope creep, the delusion that sets in at the expense of prioritisation, the fuel of Dunning-Kruger, and the carrot that would have you work more hours, for less money, on something that is destined to fail.
My friend Linda teaches drawing at University (amongst a wide assortment of things), and she was explaining a fascinating exercise to me.
Requirements: white paper, charcoal, eraser, glue stick & tolerance for dirt.
This is all about developing lots of strategies for recovering from errors and changes, and stumbling upon expressive, aggressive marks and effects that you can integrate into your safe, well-observed drawing.
1.
Start drawing the model, large, over the whole page
Once everyone has a drawing well under way, committing to using the whole page, ask the model to change one thing about the pose, and ask the students to smudge out or erase the drawing as needed to incorporate the changed pose. Then ask the model to change again, and again. Eventually the students learn to use the smudges, ghosts and erasures as constructive marks in a drawing that combines observation and expression
Give them a couple of tries at that. First time, they will learn what can happen. Second time, they can start to leverage the effects, not just recover from them.
2.
Like that, but after a couple of changes to the pose, stop the students and tell them “Tear your drawing into two pieces and keep the one you like better. Crumple the other piece up and throw it away. Look at the piece you kept. If you like it all, keep it. Otherwise, tear that in two and keep the one you like better. Lather/rinse/repeat until you have a fragment of the original drawing, a fragment you like. Glue it onto a new page and keep drawing.”
3.
Like that, but then put a splodge of white tempera paint or gesso into the palm of everyone’s (non-working) hand. Have them use that as hand-painted “white-out” to make changes to the drawing. Students gradually discover that they can not just erase but blend in charcoal and apply paint as highlights and other constructive marks. Erasure, tearing and patching fragments together are all still in play.
4.
Now play with equally messy colour – water-soluble crayola markers. Draw for a while in colourful crayola markers, then spray with water until they bleed. Integrate white tempera paint (which never perfectly covers the marker, and often blends into it) as you go. Keep brush and black ink, and all the strategies above.
5.
One of the hardest, weirdest experiences is working on a drawing for longer than an hour. Of working on something, and stopping, and coming back to it the next day… and holy shit it’s like it was made by a whole other person, and you need to look it over and figure out what today’s artist wants to do with it next.
So let’s approximate that effect, fast-forward, in the classroom, with tag-team drawing
Arrange students in a circle around a subject (still life or model), start drawing in your choice of material. One they get something established on the whole page… stop. Have them leave the drawing, pick up supplies and move to the next drawing over. Tell them to “Look at it as if it were your own. What does it need next? Do that”. Next drawing, next drawing.
After adopting several drawings, have them come home to “their” drawing and look over the many marks and styles and changes that classmates have applied. Students then work over the whole drawing, including any of the strategies used above, to emphasise and reiterate the properties they like, downplay the things they don’t like, make some corrections and integrate the whole thing into one image
6.
If students are really risk-tolerant and energised by this approach, ask the very best ones to send the drawings one direction while the artists travel the other. The drawing no longer aligns with the viewpoint on the still life (or model) and students have more extreme changes to cope with, change or embrace.
7.
Then you give them long sustained poses with complete free will and let them apply what they’ve learned when they want to.
How Could We Increase The Tolerance for Chaos in Software Engineering?
Shifting Priorities. Assignment is a choose your own adventure – you have a list of features to add, and some discussion about priorities of each. There are a series of deadlines, and at each deadline you have to hand in a feature, but it’s up to you which. The catch – each new round of deadlines, the features and the priorities change. The worse the choices you make early on (most interesting feature instead of most important? Added bells and whistles instead of infrastructure?) the harder things will get.
Shifting People. Assignment is a series of features. After each deadline, you get someone else’s code. You lose marks for re-writing it unnecessarily. Added chaos – the features are not ordered.
Group work is supposed to teach this – or the experience of working with other people in a team, at least, and sometimes it works, but too often one person takes on the task of writing everything. Other students can then feel alienated and inadequate, view it as their failure to be the person doing all the work. It’s actually a failure of the exercise.
This is a really common reason to want users to have a native app, but the question is – do users actually want alerts for this product? And if so, how many? For example news apps – they could sent an alert for every new story but that would be excessive! It’s important to be selective.
If the app overloads on notifications, users have a choice between turning off notifications for that application, or removing it. Removing it takes fewer taps.
This is the only option that isn’t available (at all) in a web-app.
Offline
Offline experience natively is really pretty easy. In the browser, much much harder. If offline is important (the biggest place I notice the lack of offline is my RSS reader, which renders it basically unusable on the tube) it usually makes sense to go native, depending on the complexity of your application and how much needs to be reimplemented.
Location
One-off location is obtainable through the browser, but anything that requires more than that, e.g. ongoing location, or location-based alerts, needs to be native.
You can upload pictures through the browser (as of iOS 6), but it’s hard to imagine Instagram succeeding quite as much with a webapp. If images are an important part of the experience, the image selection and picture taking experience is much nicer from a native app.
Audio
Background audio requires that the app be native (with some limited exceptions), if your app uses a lot of audio, for example museum apps are very audio heavy, a native one will be able to be played in the background with the screen off (screen is a major battery drain), whereas this is not the case with the mobile web.
Peak App
I prefer native apps – to build, and to use. They are faster, more convenient, better at saving state. But, I only want them for things that I use a lot, or have a short period of high usage – museum or conference apps are good examples of this. I don’t tend to download them unless I’m on wifi.
Heathrow Airport now has a native app. Which I have taken to be a sign that we have reached Peak App – I spend a lot of time at airports, but I can’t fathom wanting such a thing.
There seems to be a knee-jerk reaction sometimes that “going mobile” means “build a native app”, but I don’t think this is true. The mobile web is one option, but I think more broadly, sharing and other social apps are also part of it. People are tasked focused in the use on mobile. By which I mean, they’ll think “I should find somewhere to eat”, or “I need to check my flight time” rather than “I want to explore everything that is going on at this airport”.
Restaurants, for example, as people check reviews, and menus on the go. Personally I rarely go anywhere below an 7.5 rating on Foursquare (exceptions are usually personal recommendations). This is part of how mobile affects the restaurant business, but is the answer for each restaurant to have a native app? No, that is clearly ridiculous (although one chain does have one), the answer is about making sure that information about the restaurant is in the existing apps that users use to discover and decide where to eat.
I get asked on a regular basis how I manage to maintain a blog (and other side projects) on top of my job, especially since I almost never write anything specifically about my job. I actually wish I was better at and more productive on my side-projects, but that might be step zero – to let go of trying to be perfect and just focus on achieving something.
Schedule
I don’t have a social media strategy as much as I have a schedule. I use Buffer to schedule interesting articles I find to my Twitter feed to share 3 a day (the limit of 10 on a personal account is sometimes annoying, but I use it as a barrier on batching up too far in advance). This is one of the least important things, and one it is very hard to measure the ROI of, but has the side effect of capturing interesting things I find and making it easier to locate them again. If I’m too busy, the buffer empties out and don’t have anything to share, I don’t really mind. I read a lot, so this will typically sort itself out pretty quickly.
My blog has the far more important schedule. After about 6 months of posting 3x a week and building up some leeway in posts that are written but haven’t gone out yet, I was able to move to a schedule of Monday: travel and personal, Wednesday: tech-related, alternating general tech and more women-focused ones, Friday: reviews, notes from talks I’ve attended, the odd how-to (like this one). Sundays I post a weekly round up which serves partly as a way to collect all the interesting things I’ve shared on Twitter.
The leeway of having at least an extra week’s worth of content is really helpful, and for the last few months this has meant that I can write about pretty much whatever I wanted at any point, and then just slot it in, as it would eventually balance out.
The schedule is king, not the content. I think producing something on this regular a basis is more important than how good I think any of it actually is. Firstly, because you only get better with practise. Secondly, I am a poor judge of what people will actually relate to – some of my most popular posts I was convinced would have no value to anyone else.
Lists
My side project TODO lists is much more fine grained than the TODO list that fits on one postit at work, and includes incredibly minor things, like “change colour of X”, and “add section for Y”. It is also broken down by project. This is because the gaps between things are bigger, and returning to something really easy will get me started, and hopefully moving on to bigger things as I get into it. Also because I have no-one else to catch anything that I miss. If I forget to change the colour of X, no UX designer will ever file a bug against me.
It doesn’t matter how you do it, but when something isn’t your primary focus, you need a clear record of next steps. The hardest thing is accepting you need to document what is next when you’ve been so absorbed that you are convinced you will remember. You won’t.
Ship Small and Often
I think we can be afraid to launch our half-finished thoughts out into the world. But for side projects, I think it’s important to chill out about that and just ship where we are at. If you look through my image filter posts, you can see it building up bit by bit (including failed ideas). My Distractedly Intimate talk (and writing) builds on this and this and this and this.
Share, and iterate. Let go of perfection. Keep going. If you’ve learned something, or created something (even if it doesn’t have unit tests, or isn’t production ready) put it out there. I believe in execution over ideas, and I think being precious about keeping ideas to yourself in case someone else gets there first is pointless.
One By One
This comes back to execution over ideas. I’m not short on ideas, and being “inspired” can be a really effective procrastination technique. I document my ideas, if they are exciting enough that I might want to pursue them later, but stay focused on one project at a time modulo urgency (i.e. I might take some time away from my “main” project to focus on a talk I’m prepping).
The hardest thing is finishing. Finishing doesn’t even mean launching – it means got what I wanted to out of this project. For my image filter project, I did my experiments and learned what I wanted to but didn’t feel the need to make it into an “app”. I’d achieved my goal, and wanted to focus on something else. So I moved on to other things, but came back to it and turned it into an app when something else came up that built on it – a thing with an external deadline, so it pushed other projects out due to urgency. When that is over, I’ll go back to my next closest-to-finished-thing.
The point is – it’s hard to do side projects, making it a side project makes it far more possible. Limiting myself to one also means that I define what “finished” is.
Strategic Saturdays
It’s really easy for me to write a blog post, at most it will take a couple of hours. 30 minutes before work is will product a first draft at least, or between dinner and the gym in the evening.
It’s harder to find the time for things like coding, or longer-form writing, things that I feel like I need space in which to complete and focus on them. This is what I describe as “strategic” time. I don’t expect to find this during the week, my goal is to carve out 4 hours of strategic time over the weekend. This should also be a peak working time, which for me is the afternoon. So ideally I’ll do some smaller things or something fun in the morning, hit my stride after an early lunch, and head to the gym in the evening. Or start with a shorter workout, have brunch, and then focus time.
I call these “Strategic Saturdays” after a course I took in December, because I also sometimes use this for work-work. When I step outside my day-to-day and put together a proposal for something longer term, this is often a small focused 2-4 hour block that I carve out of my weekend. But I’ve found that unlike allowing my day-to-day job to bleed into my weekend, this has a much better ROI.
I can find one such block in a weekend, and not every weekend. So it’s important to use it well. Really focus on that most important project, whatever it happens to be, and really get in the groove. If I’ve used it well, I can often make incremental progress during the week, but if I’ve used it really well then I don’t need to.
So What?
I think side projects are helpful for a number of reasons: raising my profile externally (and sometimes internally), learning things that I’m interested in but not doing day-to-day, managing burnout by spending some time on things that I have more control over.
They are a luxury. I can make this time because I don’t need to work insane hours at my actual job, and because I have no dependants. So, I don’t subscribe to the idea that everyone should have one or that it’s some kind of measure of anyone’s ability to do a technical job.
But, I do think if you have something you really want to build, or write about, or both, you can do it without giving up your entire non-work life to it. This is how I manage that. Your results may vary.
Cookie Consent
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
