WalkUp (WalkIn when I started) is a London based startup aiming to enable you to be able to get a seat at any restaurant at any time. With their initial product being a digital queue management solution for restaurants. I joined the team at the end of March 2020 a few weeks into the Coronavirus lockdown (fun way to start a new job 🥳).
I keep additional super rough notes on this project here.
2021-02-15 - 2021-02-21
A very hectic week working to push out the bookings rate limit stuff and onboarding a new mobile app developer. It's good to have that extra capacity but reduced the amount I could help out in other areas. Had a few late ones to help get the feature ready to a testing phase. Looking back at it I think there's a few things we could improve on to manage expectations. We didn't do anything wrong with the coding approach, just how we planned and communicated the work. Here's some ideas:
The longer a piece of work is likely to take the larger the buffer you should add.
- Estimate 2 days = 2 days +- 1 day
- Estimate 15 days = 15 days +-10 days
- We stopped estimating and tracking outstanding effort left on tasks when we moved to Jira. It's harder for us to visualise how long something has left and how well we are estimating/progressing on tasks
- Double all estimations. It's always better to plan pessimistically. Even if people start panicking that we won't be able tyo do important work. It's better to force them to prioritise or get more resource than be forced into a bad position.
- Don't estimate in days. Ever. 3 weeks was probably an accurate estimation of how long it would take. But those 3 weeks would happen over 4. As other things come in, meetings take up time. That's why story points is good. And having a predicted timeline based off our data will be much more accurate.
We put a lot of work into trying to get this feature done quickly. If the reasons for why this was so important turn out not to be that good I will have lost a lot of trust in the directors. Right now I'm trusting them but it wouldn't be surprising to find out that the importance was inflated.
Some other notes form the week:
- We've had enough problems syncing the front/backend that it seems like we should prioritise the improvements to the api client
- We're trying to push for improving documentation and using Notion
2021-02-07 - 2021-02-14
Started the week with fixing some mobile app issues around animations. Rebuilt some old code there was way too complicated and used a 3rd party package that is hardly used. Never a good idea. And did some updates throughout the week on the web release which had a few minor issues.
Towards the end of the week the team started get concerned with not finishing the rate limiting work in a reasonable time so I hoped onto it on Thursday and Friday. Went into a code hole and got an insane amount done in those 1 and a half days. Kinda forgot how effective I could be when working on web stuff where there's a lot of work, but it's known work. The mobile app stuff I've been doing over the last 2/3 months has been a lot more of unknown work so progress has been slower. We should be in a good position after this week.
10% got cancelled which was a controversial issue. As the work we were doing (especially having no live customers due to lockdown), didn't seem to warrant the stress. But I got assured that there our reasons I can't know about that raises the importance. It's useful to know this as otherwise I just thought bad decisions were being made, so justifying them is always useful.
Probably going to be another intense week coming up. It feels easier to manage intense weeks when it's lockdown. We'll see what happens when we get back to normal (one day).
2021-01-31 - 2021-02-06
Turns out when you have an easy way to release, it makes development and feedback much easier. Surprise! All the work on the mobile app CI is paying off already. And the latest version of react native is making development so much nicer as well.
I've always know that mobile app development takes longer. I normally bump estimates up by around 30% of web work. But there's also a bigger increase in dealing with shit legacy code in a mobile app compared to a web app. I guess as problems are more timely to debug and resolve in the mobile app. For example say you have "Feature A" and "Improvement B". Feature A is entirely new code and Improvement B mostly involves improvements to poorly written legacy code. If you're dealing with a web app then I'd estimate as so:
- Feature A = y days
- Improvement B = z days
For a mobile app:
- Feature A = y x 1.3 days
- Improvement B = z x 2 days (this is my new revelation, previously I'd use the same "x 1.3")
Compared to web building new code is 30% longer in the mobile app, but improving old code is 100% longer in a mobile app.
Learned a bit more about how options work (which was long overdue, an official and legal doc explaining this from the company would be very useful). So I summary is:
Options give you a % of the company that you can only sell in one of these situations:
- The company is bought outright (not being invested in)
- The company goes through an IPO
- A bespoke/confusing situation where an investor may strike a deal where people can sell their options (unlikely)
- If you leave the company you have nothing
- As the valuation of the company increases the value of your shares will increase (which is good as there was a point where it was suggested that when the company valuation increases the options just got diluted to be the same value they were before)
My conclusion with this is that the only reasonable situation I'd be likely to sell my options would be a company buy out. And to figure out how much you should value options right now you need to ("value of company at point of sale" x "% of company you have in options" x "likely hood of being at the company at a point of sale"). The biggest part here is "likely hood of being at the company at a point of sale". For this I would need to take "amount of time I expect to be with the company" and use that to come up with "probability of company being sold in that time" which would be the same as "likely hood of being at the company at a point of sale". The likely hood of any startup, even in our position ever getting sold is low. Maybe around 5-20% (just from the top of my head). So the value of options at this time is going to be very low. Better to stick with mostly salary than options.
Another interesting development was doing a backend release that we had to immediately roll back as no one realised that it required the frontend to be released at the same time. It highlighted the need for a few things:
- A strict checklist for releasing either frontend or backend
Setup environments so we can test:
- The frontend that's about to go out, with the production backend
- The backend that's about to go out, with the production frontend
2021-01-24 - 2021-01-30
Had a big week of getting fully involved in the mobile app CI. Android is done (apart from a missing credential). iOS we hit a blocker by finding out how expensive it is to run on GitHub Actions. So we're getting a Mac Mini to reduce the costs. Should still be able to control it with GitHub Actions as a self hosted runner, so all is good.
Did a beta release of the mobile app and is running much faster. I had to update react native and a bunch of other libraries and turns out that's a great idea.
First week with the new CTO and going well. Also did a bit of splitting up the frontend/backend in their own repos. Otherwise not much to report. Quite a heads down week.
2021-01-17 - 2021-01-23
Finally managed to fix all the issues with making an iOS release this week. Feels good. Still missing some credentials I need for the Android app, but they'll come. Also made good progress on the mobile app CI setup. This task use to be a "1 hour a day" thing but it made progress so slow. Spending a whole week just getting back into it has expedited the process so much.
Been using GithUb actions for the mobile app CI and I think we should move over from CircleCI for all the web stuff as well. We can should lots of small optimised configs that can be manually and automatically run. I think it will help ease the tensions in the release process. And encourage us to release fast and often. I've been thinking about the whole "move fast and break things" idea and am starting to see the benefits, even if it goes against the code quality I love to uphold. If you can fix fast enough (and the code quality is still high) then it seems worth giving it a go.
Also been playing with trying to make predications on the end dates of Epics based on the estimates in Jira and who is assigned to what. It's a crazy complicated Google Sheet but a fun challenge that should provide useful to stakeholders and prioritising work.
We have a new CTO starting on Monday which will be good to see. Also feels like I should be able to learn a lot from him which I think should be one of my focusses this year. Learning how the CTO role works, what kind of backend and systems stuff I'd need to understand etc.
Also hired a new frontend developer so yay!
2021-01-10 - 2021-01-16
Still getting into the flow of the new year this week. We've moved over to Jira so there was a reasonable amount of setup and admin related to that. It feels pretty obvious that some of the stakeholders are feeling like progress isn't being made towards our main goals for the year and are getting worried. To me it feels premature to worry about long term (3 monthly) goals in the first week since they've been defined. Especially as we still don't scope these goals in much detail so there needs to be time when starting on these goals to define and organise them.
I wonder if it's a problem of having non technical stakeholders in daily stand-ups (whilst we don't have a CTO) or whether there is a problem that I'm underestimating or if it's just a matter of how we track progress. As always it's probably a mixture of all of that.
I got called out on being too focussed on CI and quality related issues by a senior dev, which was interesting. It really set me back as in my mind we are right at the minimum standard and we're going to be running bigger and bigger risks of the platform going down or parts of it being unusable for periods of time. I think I am more prioritised on improving what we already have than feature development. Maybe my tolerance for risk is lower than everyone else's. Which is an important thing to balance in a startup. As by definition it's a risky business. It could be why my startups failed and this one is working. So perhaps I should ease my rigorous charge for quality until we have the resources to deal with it.
Since I've been here we've had 2 major issues from what I can remember. So in 9 months that's 2 issues -> 2 / 9 * 30 -> 2 / 270 -> 99.259% daily uptime -> 0.74% chance of having a major problem in any given day. That's too high for a normal company but for a startup? Not sure.
Also had our first 10% time all day on Friday, where we get to work on anything we like. I cancelled my usual day off to get involved. Looking back at it I'd rather have my day off and work on non work related projects. That no pressure time is way too important for me.
The work I did get done was related to the mobile app release and CI, slow progress due to the admin related stuff this week and helping out other people. The sharing of the CTO work definitely has an impact.
Still learning to try and not talk over people, interrupt and force conversations. Not sure how obvious it is to other people, may just be getting in my head. But it's a good thing to work on. I just get too enthusiastic 🥳
2020-12-07 - 2021-01-09
Christmas period so not as many updates as usual.
The biggest challenge over this period has been our CTO being unexpectedly off for most of this time and we still don't know when or if he'll be back. It's highlighted some interesting issues. The biggest one has been access. I've been finishing off a new mobile app feature and wanting to release it, but because we never finished off our continuous deployment system for the mobile app it still has to be done manually. Which requires specific keys and setup on your machine. I don't have a problem building alpha versions and distributing them but I have come across problem after problem trying to do a production build and release. As normally the CTO would do it on his machine. So the big learning here is to not underestimate the importance of a full CI/CD system. Every product should be able to be tested and released in an automated way from day 1. And if any manual process needs to happen (e.g. app store release) there needs to be very clear documentation with a checklist and multiple key people who have the access.
Outside of the deployment stuff the other issues with not having a CTO have been relatively minor for now. Probably because Christmas is a bit of a dead period especially with lockdown as well. And with me and the senior backend developer we have things pretty well covered. I'd imagine that when it comes to pitching for series A or meetings with key people who have questions about the full stack, then that's when we really need someone who has the overview of both the frontend and backend. And if the team was bigger the importance of that overarching person would be felt more.
It was also interesting coming back after 2 weeks off for Christmas. With me and the CTO off the PR's just backed up as there was no one to sign them off. Which is fine an inevitable when the team is so small. Would need to figure out a different solution over a busier period. If there was actually some important stuff to get through I'd probably have made the effort to help move the PR's along whilst off.
Another interesting development was seeing various little bits in the dev team that have changed and conversations that had seemed to go on that maybe wouldn't have if I was there. Which is good (for the team) but made it feel like coming back and finding out everyone had been complaining about you. Although probing a bit and finding out what the issues were I found out it was more a communication issue about why we have the quality standards we do and figuring out how to build to that standard in a more lean way. No one seems to have any issues with the standards, it's been more of a learning curve and my learning is about how to ease people into that better.
With the start of a new year we also had a whole bunch of meetings around what the focus will be this year and what resources we need for it. Really fun going through this strategic level thinking and seeing the awesome prep work that goes into the series A deck. Looks like we're going to try and expand the frontend team ASAP which is awesome as we always have more frontend work than backend. It was a tricky decision as we could progress without, just wouldn't get as much stuff done and not to as high a standard. But as a startup we have to make some gambles and push for the win. I feel like we've probably been quite conservative on that since I've been there. In terms of spending anyways (didn't realise this until someone else mentioned it).
Either way a curious start to the year but very positive. It's gonna be a good one.
2020-11-29 - 2020-12-06
Been working just on the mobile app this week which is nice. Although it does highlight how awkward our dev process is when it comes to the mobile app. As such didn't make quite as much progress as I'd like, but things are going in the right direction.
Had another office day, which is always super fun. Ran a workshop on our process idea -> release. I feel like we're getting better at keeping meetings on track but there's still work we can do to stay focussed and effective. The workshop led to some ideas around defining the stages we work in and having owners who allow tasks to move to the next stage. Interested to see exactly what comes out of this.
2020-11-24 - 2020-11-29
Identifying what you're not working on or not spending time on is super important. As it's easy to be so focussed on something that you drop the ball in another area. Our system architecture stuff is starting to get like that. We need to spend a bit more time on CI/CD an internal tool stuff to keep things running smoothly and prevent bigger issues piling up.
Found out that one of our core and awesome devs is leaving, which sucks. But we have a new senior/lead level dev joining this week so that's super exciting. This got me thinking about what we can do to help keep and attract amazing talent. And had a good chat with Amos about this. Here's some highlights:
- Make the dev experience as easy as possible (internal tooling, documentation, well defined processes, fast technology)
- Allow devs to work on fun and interesting challenges (most of the normal work we do can lead to this, but would be good to specifically make sure there are stimulating tasks in every sprint. And fun ones e.g. festive branding)
- Let the wider tech community know that we are a fun an interesting place to work at (hosting events, writing blog posts, some social posts about us)
Was also thinking that at some point we'll want to let content editors do things like adjust the logos we use, the order of content on pages etc. Traditional CMS stuff. Contentful will be easy to get going with this, but we'd probably want to start using their environments features. So we can test stuff on staging before publishing.
2020-11-17 - 2020-11-23
Had a big week of testing our new bookings functionality and fixing bugs. Had a bit of a bottleneck with having lots of PR's ready at the same time and waiting for builds to finish before merging in. Trying to have all PR's signed off by the product team before they can be merged may help with this. As it staggers merges. Means we don't save up lots of stuff for a release (as releases should be able to happen at any time), and should catch issues earlier.
Did a lot of thinking and writing out some draft flows around our process. How do we specify tasks, add enough acceptance criteria, get them tested and relay feedback on progress. It's normally the project manager role but we all need to take some of that responsibility until we have one. Maybe it's a role we could look at someone like Frazer helping us out with? He is the COO?
When giving people responsibility I need to be a bit more precise and direct. It's like that group bias where asking anyone in a group to do something isn't very effective, but pointing to an individual in the group and asking them is much more effective.
It can be better to show rather than tell, when explaining something (https://en.wikipedia.org/wiki/Show,_don%27t_tell), I think I do this quite a lot with code examples, but it's useful to have come across it in some of my reading and realising the importance of it.
There's also been a few moments in the last week where I feel like I could have been much more concise in explaining my thoughts on something. It's part of the downside of thinking through talking. But giving more pause between thoughts might help. It feels a bit like falling into the classic programmer fault of over explaining and boring people with detail. Something to watch out for.
2020-11-07 - 2020-11-16
Had a new starter this week! Yay, time to share the load. This period has been a lot about process. As we grow so quickly and we don't have the money to hire for all the roles we'd love to have, we have to figure out how to share those tasks amongst the people we do have.
My theory on that is to implement pretty strict processes with templates and checklists for all the tasks that we would ideally hire for. Reducing the amount of time we have to think about what we're doing and sharing the tasks between everyone instead of dumping it on an individual who wasn't hired for that.
The main tasks I'd like to define processes for are "specifying tasks and acceptance criteria" and "quality assurance testing".
Also want to make sure anything that goes into develop can be released. By having a better QA process before we merge branches in. Actually involving the product guys at this stage. Lots of smaller testing rather than 1 big test. Also means we can release more often.
Would be good to have better changelogs as well. We enforce it, but people write notes rather than what you would expect in a nice changelog. That non devs could read.
2020-10-26 - 2020-11-06
The last 2 weeks have been a big exercise in managing contractors and seeing their capabilities. I gave them some much more complex tasks to see what would happen, one did really well the other did not. So I had to step in to cover the lost time. Was an interesting experiment, probably something that is worth doing to judge people's capabilities but I should find a quicker and less impactful way of doing this. Probably by reducing the size of the task but keeping the complexity. Most of the issues with this come down with our lack of details when specifying tasks. Which is a tricky balance when the team is so small and there's no dedicated project manager.
I've been thinking about how to improve our product quality and development speed as well. Most of the ideas are around how to setup processes to ensure we are increasing the amount of testing we are doing. Things like:
- Scripts that fail the build of test coverage has not increased
- Update my chrome extension to help encourage me to actually use the checklist on PR. Or implement for everyone.
- Implement a policy that all bug fixes must have tests
- Make it super easy to add test
- Make it super easy to see the results of all tests (in CI, maybe for vscode as well?)
- Get the end to end tests running on CI
- Encourage devs to be working inside cypress
- Spec tasks in such a way that it can be very easy to write the end to end tests
I always want to increase the priority of any tasks that reduce or remove time for devs e.g.
- All requests that could be done by non devs by adding something to the admin panel
- Reduce the amount of time managing PR's e.g. auto merge develop if possible
- Reduce the amount of time the CI takes
- Improve the dev start process
I also want to find some way of enforcing a policy of: Every question that gets asked that could be documented should be. And make the documentation super easy and sexy to edit. Maybe ask Jani about best practices.
Going into the office was really fun. Lovely banter. Lovely people. Definitely need digital representations of post it note stuff we were doing. Having a digital draw on screen would be awesome. Can put post it notes on there as well. Should encourage more formal processes for some things like documenting user problems and feature ideas.
Got to be more direct with goals, expectations and contractors. Split the tasks down as small as possible, do not underestimate the benefit of this.
2020-10-11 - 2020-10-25
A mix week of writing specifications for the next version of our bookings platform (which we've already started building, whoops) and getting really into some base level component coding (table component). A big part of this week has been around getting fustrated with how new features and improvements are presented to us, specified and then worked on. I guess it's the problem of not having a dedicated designer/UX person, customer development specialist and project manager. Although the solution can't just be to hire as resource will always be a problem. So it's time to come up with a cunning solution given what we have. I think this means define some very rigid procedures for customer development, UX development and design, writing acceptance criteria, accepting work as a dev team and relying feedback on progress. So something to think about, I want to figure out a proposal for how we manage all this.
When you don't have much resource and growing fast maybe one of the best things you can do for effectiveness is documentation. If you keep getting people in, contractors or trying to hire people, then documentation can save a lot of time and context switching.
Also had a great convo with the directors about priorities and how to balance work on bookings versus improving the UX and performance of our core products (especially the mobile app). If we try and do a mixture of both does that mean we do a poor job at both. Although less focussed work needs to go into improving the current product than would need to go into bookings. The work on bookings is much more uncertain and a bigger job. So we should spend the time to get that right. And offer something that feels competitive rather than just less features than existing platforms. If our focus is usability, flexibility and speed. Over full bookings and table plan modelling. That could do it. Seeing as we want to target people who are max 50% bookings? As we don't see a future in higher than that. So let's build something very specific to that future. We need to make sure that that's how the features appear to the vendors. And when we market it. It's not a light version of bookings it's the optimal bookings solution for the vendors focussing on people who want a table at any time, the same way you'd use Uber, which do offer a light version of book in advance.
It's really easy to make shit stuff in a shared package that will just break over time. It's worth going back over and really thinking through the decisions.
2020-10-04 - 2020-10-11
Very busy week working on an important new feature. Getting it ready for internal testing, idea is to go live next week so can tell you a bit more about it then. Biggest learning from this week is similar to last week, in that I don't think people should be encouraged to work late for new feature development. Not in a start-up at this stage. If things are on fire and going wrong then that's allowed as it's an exception that can be damaging. Along with this I've been reminded about how annoying timezone support is. Will be looking at solutions in the coming week to make this easier to manage.
2020-09-07 - 2020-10-03
Thinks continue to go well, been focussing on mobile app performance improvements. Which it desperately needs. But it's a slow process with so few developers. Got interrupted in this work to build an exciting new feature, but we have a very tight deadline so it's all systems a go. Will update once this feature is live, should be in the next 2 weeks. Been furiously hiring contractors and still trying to find permanent people. It's a long game, but happy with the contractors we now have. Can be very hit or miss. Biggest learning is to keep pushing on pessimistic estimates and not to box yourself into a hole of committing to work that can't reasonably be done. Think I handled this well and made my points obvious and clear, but think the rest of the team need the point to be hammered home more. It leads to the classic dynamic of having a lead dev just saying no at some point. You can do what you can to reduce scope but there gets to a point that some things just can't be done in some timelines. Although it's a harder question than that, because technically you could sacrifice quality, performance and reliability to do it in those times. But my stance for us at this stage is that that path is more dangerous.
2020-06-21 - 2020-09-06
During this time we've seen incredible growth, literally exponential month on month. Very exciting but we can't grow the tech or team quickly enough, so we're trying to hire like crazy and focus on performance and reliability. There's been interesting challenges around deciding on priorities when there's so many exciting and essential things to do but we can only do about 5% of it.
I've also had some interesting thoughts/work around theming and allowing white labelling. Mainly that theming a large scale application should only be concerned with colour theming. Having spacing/margins in themes can get out of control easily and people are more likely to abuse it's use.
We've had a lot of pain trying to setup thw mobile app CI/CD pipeline, which was inevitable. Would have been easier to do with a blank app, but we're making good progress.
We've also had some interns which has been a lovely experience. Nice to help people out from such an early stage, especially in such an exciting environment like ours.
2020-05-01 - 2020-06-20
We finally got another developer 🙃 A full time senior backend engineer which greatly helps our capacity as stores around the world start opening again and testing out our platform. For this we spent some time focussing on localisation support (which there was none of before). So I had a fun time building a separate package for managing this and allowing us to have different copy depending on whether a vendor is a store or restaurant (otherwise we could have just used another 3rd party library).
2020-03-03 - 2020-04-30
For my first few months there were only 6 of us, with the development team consisting of just myself and the CTO (busy busy). My initial focus at the beginning was to audit everything we already had and figure out how to proceed development in such a way that we can scale more easily and have a higher level of quality (mixed in with generic bug fixes and minor feature improvements). Luckily (for us) COVID-19 had shut down all restaurants so we didn't have a live system to maintain which allowed us to make some swepping changes we wouldn't usually have capacity to do. Which definitely put us in better standing when restaurants come back.