Deliverying a project
In my first year, I was part of something that not many first-year software engineers get to do and that was delivering a project from scratch to production with real customers. This is something that you dream of doing from the first time you say you want to be a developer, yet not many people actually get to do it. The typical entry point to your career is to start out debugging some enterprise code in Java or some other enterprise language. You will typically spend the first year if not longer doing this, never be trusted to do more than debugging something that has been out there for centuries. Before I got my job at Our Very Own I applied for a job where I would have been doing enterprise Java day in day out. I’m very glad I didn’t even get an interview because instead, I was “stuck” on an Elixir/React project in the education space. We took the idea presented to us from the two founders, contemplated what technologies we should use, set up an MVP goal, had a release date all that good stuff. We spent the first 6 months developing the product to release for a strict deadline. Like 100% of projects, it didn’t hit that date, which was okay because as you find out in projects just because you said it has to be done by this date doesn't mean that it's actually the perfect time. As both parties were new to the education space we found out that in fact, the deadline didn't have to be till about November which was great because we needed that time.
We ran the project in an agile manner, running fortnight-long sprints which were great because we could set out the tasks we wanted to complete and at the end of it we would have a retro, discussing what went right and what went poorly and how we would fix it in the future. When your part of a team in a big enterprise, for the most part, you will work in a small team which is one of many inside a large team. Your team will be sectioned to a very specific part of an application. You might be part of the payments team, where it's your job to create, debug and maintain all the functionality related to payments. That's it, you won't handle other features like accounts or some other feature. This is fantastic for when you start out as you're going to be in a team with some other juniors, maybe some kids, most certainly some seniors and there will probably be a lead at the top who communicates with the other leads from the other feature teams. This structure is one of many that an enterprise could possibly have but when you work on a startup you don't have the luxury of money and large teams. Each team member has to wear many hats, everything is done at speed with corners taken in as easy to recover manner as possible. For instance, our initial automatic deployment was only semi-automatic and it was pretty messy, it took a long time to complete but we weren't DevOps engineers so you can't expect too much. That's what happens in startups, you do enough to get features over the line because you have very little money and you need these features out there so people pay you money.
You learn a lot when you deliver a startup project, you have a working knowledge of pretty much every aspect of the project, you take part in aspects that you don't know anything about so you have to get up to speed real quick. You come out of the experience a way better programmer but you can get into bad habits, you don't get the kind of quality you would of an enterprise project, you simply don't have the time or the money to do so. You can get at least some of the quality you would from enterprise development, you do this by having the right mix of seniors and juniors, as well as the right culture. If you just have a bunch of developers who aren't willing to share their knowledge then you won't create a culture of progress. However, if you have a bunch of seniors that want to help others and you promote the practice of sharing, you get juniors that can really create quality code.
I learnt a whole lot from being part of a team that took an idea and bought it to life. I learnt that in a startup you have to wear many hats. Your juniors take on much more responsibility than you could imagine. You learn every aspect of the code, the business, deployments and customers. You learn from many, many mistakes when you go to the market and you iterate on them rapidly. Delivering a startup project is VERY different from that of an enterprise but I love it. You get your hands dirty with all aspects of the project and you take all the blame when it goes wrong, but hopefully, you learn from those mistakes. You get lots of chances to fail, you also get lots of chances to really succeed. I did 100 times more than I ever thought possible in my first year and although I had some serious struggles I wouldn't change anything about it and how I was apart of a team that delivered a startup idea to market. They say it's not about the years worked but the quality of those years, I might be a little biased but my first year feels like I learnt that of ten.
I’m always learning something new and with Pluralsight I can have unlimited access to all things programming. But hold on, it’s not just programming. There’s photoshop, visual communication, manufacturing and design. There's a whole bunch! Sign up today and get a free 10-day trial!