Time finally came this week to roll up our sleeves and do some actual development. My part of the work this time was to integrate firebase into our app, and add the login / registration functionality. The result is the below:
My contribution is that first screen. The one with the login and registration buttons. But notice the screens after that- the ones with the navbar at the bottom along with their placeholders. Those are the work of my teammate. The gif lends itself to a key difference between (most) development work during school, and the development work done in the real world.
Compared to school, very little of my (albeit small amount of) real life experience has been spent actually writing lines of codes. Since starting an internship back in mid-June, much of my time has been spent on knowledge transfers, code reviews, reading documentation, or clicking my way through endless amounts of tools and workflows. All this in the name of making sure everyone on the development team is on the same page regarding development for a codebase millions of lines long.
All this extra work is needed because in the real world – it’s not just a single person in a hoodie with the lights off hacking away at whatever app or pet project they are working on. Developers of projects come and go all the time depending on business need. As Robert Martin, author of Clean Code, says:
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”
Martin makes the point that because we spend so little time writing code as opposed to reading it- we should make code as easy to read as possible. But there’s also a whole slew of practices that come into play when developing as part of a group as opposed to developing on our own.
First – version control suddenly becomes a lot more important. Working alone, all I really used to use git for was as an super-powered save-button, spamming commits like a kid cheating a game with constant save-states. Working as a team; however, means that a number of us can work on our apps features simultaneously– nearly doubling our productivity.
I say nearly doubling because adding extra folks to the development process also adds to the complexity I alluded to before. Instead of just pushing to main, now my teammates and I have to checkout branches to work on our features. And then, when merging our features back to main, there are often conflicts that we have to resolve.
Second – automated testing becomes more important (and more impactful), as adding testing coverage to our features when we deploy them means that when another person, potentially unfamiliar to the codebase, makes a change – they can do so with confidence that they didn’t break anything.
Clearly- more people, more complications is the theme of this post, but when even the most successful single-person passion projects take the developer over four years, it’s simply the reality we have to live in order to keep up with the industry.
