Home | Games | Programming | Music | Mathematics | Blog | About
Throughout my life, I've only really looked forward, not back, and I've never really written about any of my thoughts at length, preferring them to remain as the vague shapeless blobs rather than to crystallise them into definitive meaning. This is the first step, of many, in starting to rectify both issues.
To set the scene, the Alacrity Foundation is a charity that offers a paid 15-month entrepreneurship course targeted to graduates like me, in which you would obtain both knowledge and skills needed to run a technology startup. Additionally, to me, it seemed like a great and unique opportunity, and having come to the very tail-end of my university studies, something I could use to differentiate myself for a future job if the whole startup thing didn't pan out. Looking back, this was correct on both counts.
In terms of the actual experience I had, it was, whilst positive in hindsight, a real mixed bag, and I find I have a tendency to look back with a rose-tinted tinge regardless of the memories. It was also simultaneously eye-opening and yet also solidified quite a few of my initial preconceived notions. A lot of the focus during the course was split between business and tech, so I'll categorise my thoughts in a similar fashion.
Most of my time was spent getting myself up to speed with programming and all that jazz, so I didn't actually get much further than the baseline understanding everyone needed. Whilst bits and pieces of business knowledge were fairly enlightening to read in the 'obvious in hindsight but put far more coherently than I could have ever done' (describes Bill Aulet's Disciplined Entrepreneurship book to a T), but the main experience I got out from trying to understand further was honestly bafflement and confusion.
My issue was that high level concepts made sense, but trying to apply and implement specific steps/analyses/techniques (anything at all, really) were not straightforward in the slightest to me. I'm a mathematician so I prefer stuff having concrete definitions, and here this preference felt entirely detrimental. There seems to be an inherent need to have implicit confidence in the work you produce, even with frameworks around to structure said work, and I can't have that confidence. It didn't help that the industry we were building our product for (Wealth Management) was one that was, in the grand scheme of things, completely alien. Wealth management is something I shouldn't have to care about as an industry, given my non-existing assets worth managing. So we were stuck at square one trying to get out any information we could, and struggled a lot on this front.
However, I can't also, in good conscience, pin it all down to confidence, as I did often recognise a significant disconnect in certain business techniques and approaches used, where the school of thought needed was incompatible with mine. The first, most obvious example that I've used as a yardstick are elevator pitches. I remember being hammered home the importance of a catchy elevator pitch, and given advice on how to improve it using some vague guidelines and the 'its good when you know its good' advice. I've never really understood what makes a good elevator pitch, and I've grown to dislike them heavily, although this purely a personal issue. The elevator pitches strengths i.e. a short and sweet description outlining an idea or product in ~1min, are not really strengths to me. I'd prefer something longer and with more detail to read rather than listening to something snappy. This is just one example that was most prominent in my mind, but it certainly was the first to recognise a fundamental disconnect. Beyond that, there's not really a whole lot to say. I tried, and there's not much more you can do.
Learning to program by the seat of your pants is, whilst definitely the hard way, also one that gives me the most enjoyment and fulfillment, and having come back out of this graduate course learning and gaining experience in a large range of software development areas, despite only doing this for a year, really gave me confidence that I could, at the very least, become a competent developer in whatever areas I wished to specialise in. On a personal level, I did wish that there was more mathematics involved as that's who I am, essentially, and that while studying maths in Uni helped with logic, intuition and all that jazz, I don't think it helped substantially more than studying any other STEM or STEM-adjacent subject. Have found wanting to lean into languages like Python, given their extensive math libraries, however I've also started to explore further afield and look at array programming languages, such as APL.
Picking tried-and-tested languages and technologies is especially important when learning, as I found you need the popularity to ensure there's plenty of online resources to augment learning alongside any official documentation. Even if it just means using stackoverflow to debug a cryptic error. We were creating, at its core, a CRUD app, so we initially Javascript frameworks for the front and backend (Vue.js and Express.js) with a relational database (MySQL). We made a few tweaks along the way to this setup, such as using typscript, and switching our backend framework at one point to Nest.js (more opinionated to help structure, used Express.js under the hood so not a dramatic change realistically), but by and large we stuck with what we had, despite being safe in the knowledge that our codebase was always small enough to adapt it if we so wished. Iterative approaches here makes sense (although the very initial stages of a codebase are a special case in my book, without the very preliminary structure you can't do any kind of iterations). Would contrast that getting a good database schema is a lot more important, and so I would rather not take such an ad-hoc approach with it and instead plan it out in detail. You'll still likely be wrong, but less wrong and less painful than just trying to cobble together a schema, and besides, the code you write will rely far more on the database schema being properly designed than vice versa, so I'd regard a schema to be far more immutable rather than some code, especially in a startup where anything that turns out to be unnecessary is tossed quite quickly.
When developing, especially due to having to learn as I went along, a lot of the time I would quickly realise there were hacky ways of getting things done, and a 'right' or 'correct' way. Worrying about getting things done the right way was, and still is fairly meaningless without using the hacky implementation as a stepping stone. (I discovered later that this is somewhat similar to the TDD Red->Green->Refactor cycle sans tests, although I would always test it manually myself as a verification step).
What I've probably spent the most time thinking about, however, is all about Agile and Scrum, given how widespread the process appears to be in the software development world. While my very initial introduction wasn't great (a lot of the marketing felt more like proselytizing with its ONE TRUE WAY of developing software), but given some experience with Scrum I've began to form some opinions on it, and by and large, its honestly exactly what I expected a methodology to be, because its just like any other methodology in concept. A big box of ready-made tools and processes, wrapped in an ideological bow, and similarly, some of these tools and processes pass the smell test, and are useful. Others, however, are not so useful in my opinion. Overall, there is good sensible stuff there, but a lot of it is derived from the Agile Manifesto itself, and I'm not sure Scrum is worth the overhead, or even more fundamentally if its a good methodology full stop, beyond serving as the agile equivalent of training wheels. The biggest problem to me with Scrum are the sprints, which are pretty fundamental, and there are a multitude of reasons why I believe sprints are subpar.
The short, bullet-pointed tl;dr version:
My number one complaint is the estimation aspect, and this is mainly an intractable people problem, that I'm not sure can be fixed. The problem with estimating, in time specifically, is that people have been shown to suck at it, time and time again, enough that are various observations solely about this (e.g. Planning Fallacy, Hofstadter's Law, Parkinson's Law). Now story points are an attempt to get around this hours problem, but from experience this doesn't really work. By being so deliberately abstract in representing 'complexity', the estimates become difficult to reason about, and so we want to think said estimates in more concrete terms, or rather, how long it will take. And so we're back to square one. Abstracting over empirically observed faults merely hides them from view rather than solving them. Given how Scrum is 'founded' on pillars of empiricism, this empirical blind-spot becomes far more egregious, and a lot of my complaints cascade down from this fundamental axiom.
My other significant complaint is, well, sprints themselves. They are poor in every sense, right down to the word sprint itself. Sprints run (no pun intended) on perpetual deadlines that are 'commitments', despite being comprised wholly of tasks that are themselves estimated. This seems to suggest that adding together multiple tasks of uncertain length/complexity/etc. will somehow reduce its uncertainty, which is obviously untrue. Even the sprint guide acknowledged this issue of 'commitments' back in 2011, but no-one appears to have noticed. This means that the heavy overhead of sprint planning is done solely to make false promises, and a perpetual excuse to bring out the stick if a sprint fails. Being reminded of this and your chronic time shortages at every step is a perfect set-up for constant worrying and panic, and I don't really need to outline that perpetual panic is not conducive for doing anything well, let alone just software development. Hence the very tail end of sprints, unless vastly 'underfilled' (in which you just bring in new work anyway, again making the value of having sprints seem questionable), tend to be chaotic, with everything needing to be tested, reviewed and merged all at once. All in service for a deadline that realistically does not matter one jot. Embrace the fact that work and productivity inherently ebbs and flows, rather than fight against it.
Other smaller assorted tidbits and observations not really worth elaborating on goes here:
In hindsight, whilst writing this up, this has perhaps been more negative than intended. Not the plan I had in mind, but the innate negativity bias is strong, and its much easier to comment upon things in this fashion. This is absolutely not to say that I didn't enjoy my time at Alacrity wholesale, like everything there's a mix of positive and negative, and that it was definitely worth the experience, even if the relentless pace did end up burning me out quite significantly. My current job now is a lot more corporate-y and safe, and while I now appreciate the relatively relaxed pace and safeness, its very easy to see how this is not for everyone and why certain types and groups of people are drawn to the entrepreneurial and startup culture. Plus this gives me some experience if I ever wanted to construct an escape hatch outside of the corporate world.