Well I’ve just finished my internship at Fidbacks, not crying me eyes out but nearly. I’m gonna miss a lot of stuff, but the worst will definitely be those monday morning croissants! :D
It was some experience, working with a week-to-week schedule, sometimes even day-to-day. I’d always heard about “X startup launched a product which does Y for Z”, but never really got into the innovation business (last year was lab work, that doesn’t count).
Diving into the startup salad got to me big time.
So here are a few notable things I learnt from these few last months.
Obviously, this comes first; most of the time I spent at Fidbacks was building features which were either openly requested by customers or at the top of the “TODO” list. When doing this, I knew that what I was working on would most likely be deployed the next week or two, and needed to be pitch-perfect.
I usually could settle with a “it works” version, but by knowing it would probably be in production on such a short notice, my spirit was filled with motivation and I needed everything to be perfect. Which, in software development, is a big no-no.
Now this is a well known concept, and you can probably guess what happened. Overcomplexity. More database tables, inheritance, mixins, app-level libraries and all sorts of other things. Wasted time, complicated diffs and the very annoying “why did you touch this file?” question when the team leader was reviewing my PR.
There’s nothing like experiencing what you’ve always heard about.
Mainly for open source software that is. During my internship I was frequently in contact with members of the Ruby community, mainly due to issues with their software. There’s nothing more annoying than finding an awesome gem (library) that does exactly what you want, with few code/configuration…and it doesn’t work.
In my case, instead of giving up and looking for something else, stubborn as I can be, I decided to fix the issue most of the time. Now with Github, this is rather simple: fork, commit and pull-request. Nothing new compared to my company’s workflow at the time, which was rather comfortable.
When you’re in a large company with many issues and ongoing conflicts, you can’t always take the time to get to know the people you work with. And that sucks. Obviously, when you’re simply trying to get your product on track and deal with minor bugs with customers or even deciding on the next course of action for the product, well you’re not really thinking about next month’s check and how you can make it bigger. No, you’re in a company who isn’t old enough to categorize people and have their whole career planned out…and therefore dehumanized. You’re in a company who values one-on-one respect and self-development through your work. So bond with your team! Enjoy it while you can. ;)
Yep, didn’t really feel like filling this in, since it seems a bit obvious.