Big Data Pipelines as Serverless Microservice's
### Apache Spark vs Serverless Apache Spark, Serverless, and Microservice's are phrases you rarely hear spoken about togethe...
Read MorePublished on Dec 15, 2019 by jhole89 on startups, culture
I’d like to preface this by saying I don’t want this to be read as is a rant against start-ups, because I had a lot of fun whilst working with one, but I definitely went into it with rose tinted glasses and got slightly burnt, and as a result wanted to share some of my learning’s.
For a bit of background, I spent a year working with a medium size start-up (approx. 50 employees) as a Senior Python Developer. Prior to that I’d spent 3 years working my way from Junior Developer up to Senior Data Scientist at a large consultancy. During my time at the consultancy I had specialised in Data Science and Data Engineering with Python and a little Scala. Given my lack of traditional CS background (my background is in Mathematics), and my main exposure to start-up culture from shows like Silicon Valley, I always consisted myself “not good enough” to work at a start-up. I considered them reserved for programming elite, the kind of 10x developers you hear about in hushed whispers. So naturally when I got the opportunity to join a start-up as a Senior Python Developer I jumped at the chance, though with a lot of trepidation to what I has signed myself up to. These are some things I learnt in my time there, and some things I wish I had known before.
On my first day at the start-up I found myself review a repository scattered with global variables. Literally, the first line of code I read was a long list of global declarations. Most annoyingly these were completely unnecessary, and could be easily refactored away. It turned out this code had been written by a Data Scientist within the company who had come straight from university a few years ago - they didn’t have any real world development experience. This is when it hit me, start-ups contain everything from inexperienced graduates through to seasoned veterans. I quickly realised that my concerns over being “good enough” and impostor syndrome were misplaced. In short if you want to work for a start-up, go for it, you’ll be fine.
Due to the varying talent startup’s employ, you’re bound to find yourself talking to people with vastly different programming backgrounds to you. This means they’ll have a wealth of experience that you may not have explored yourself. In my time there I met a Javascript developer who had just finished a React bootcamp, a Python developer who used to write desktop applications using PyQt, an ex-Java developer worked at Lehman Brothers prior to the financial crash, a cloud native DevOps engineer who used to be an optometrist, a Python & Angular dev who was trying to build his own football startup on the side, a young Scala dev who had spent a year working for a bank before calling it quits, a Rust aficionado, a Gopher, and many more. All of these people had come from different backgrounds, with different experiences, and different takes on things. I learnt a lot about different languages and design patterns by simply listening.
We’ve all heard the Facebook mantra before - “Move Fast and Break Things”…its bullshit, and worse its considered to be an ideal to aim for. I heard this time and time again, management, project managers, “scrum masters” (I’ll save it for a separate rant, but I don’t believe in full time scrum masters), product owners, and HR. They had all seen the monoliths of Facebook and Google evangelising the attitudes of “MF;BT” (Move Fast and Break Things) and becoming the tech giants that they are. The problem with this is that they weren’t interested in fixing systems and we just started crippling ourselves with technical debt. In one case the sales team had signed a deal with a client for a type of configuration that we didn’t, or couldn’t, support due to a fundamental base concept the whole architecture had been designed on, which they were now saying didn’t apply. To correctly re-architect the system to account for this one client would have taken months of work and careful re-write. Despite stressing this it was pushed through, not with the substantial re-write, they wanted it done quickly even though they knew it would cause other issues in downstream systems. We managed to do it via a nasty hack and hardcoding this customer into the system, on the understanding that we wouldn’t sell this type of deal again. Of course we never got the time to go back and fix this hack properly due to other projects being prioritised…then sales sold it again, and again. To my knowledge someone is now manually hardcoding all those clients into the system, we moved fast, we broke that system, we never fixed it.
With the knowledge that MF;BT is just bullshit, I started looked at why the “MF;BT” group were so successful - Facebook, Google, Uber, Spotify; what did all of these have in common? The answer is very simple - they just started with one product and focused on doing it right. Sure we now have Google building smartphones and speakers; Facebook with it’s own marketplace, along with WhatsApp messenger, and Instagram; and Uber delivering any food you may want; but none of them started out with that as a goal. All of them made their name by just doing one thing well - Google had its pagerank search, Facebook a simple and clean networking platform, Uber a simple phone based taxi app, and Spotify a free music streaming platform (no podcasts, no radio, just music); so well that they were able to monopolise the market in that area to build out massive customer bases. Only then did they start diversifying into other areas and markets, by this point they had the customers, the investment, and a stable core product to fall back on - this is why they’ve been so successful. On the flip side, my startup was trying to diversify itself across every market within it’s industry, spreading itself and the technical staff very thin. As a result we had nearly 50 different microservices running - and that was reflected in our AWS bill, but without the client base to pay for it. We should have just chosen one thing and just done it well.
Lastly I want to loop back to my original thoughts, that startup’s were for the technical elite. The other side of this
was that I thought startup’s would be full of the latest tech and best solutions to gain a market edge, they even listed
“Machine Learning” on their webpage. Well, that “Machine Learning” was actually the code littered with global
variables, and the closest it got to ML was a load of if-else
statements which simply sent a request to a microservice
depending on the response it got from another microservice…that was it, that was their “Machine Learning”. What’s
worse was that they were winning startup awards for their “Machine Learning” platform from people who had never even
looked under the hood, because it all just came back to the marketing around what they were actually running. The tech
didn’t actually matter, only how they could market it did.
And that’s that. It’s not everything I learnt at the startup, but that is everything I wanted to talk about, and some of my overall problems with the startup industry. I’d like to reiterate that I did enjoy my time working for a startup, and I learnt a lot of skills from my colleagues which have made me a better developer. Looking back I wish I had gone to a startup earlier in my own career, as I definitely put it on a pedestal which made some of the issues harder to recognise and accept, but overall it was a good experience to have. So honestly, if you are thinking about joining a startup, go for it with eyes wide open - just don’t believe the hype.
### Apache Spark vs Serverless Apache Spark, Serverless, and Microservice's are phrases you rarely hear spoken about togethe...
Read MoreI’d like to preface this by saying I don’t want this to be read as is a rant against start-ups, because I had a lot of fun ...
Read More