If you had told me a year ago that I would be working as a developer now, I wouldn’t have believed you. A developer? Me? Surely that’s waaaaayy to difficult.
But what I barely even dared to dream of when I applied for various bootcamps in September 2014 has indeed come true: I work as a developer now!
Have been for over two months actually. And I write code all day! For money! And that code actually gets merged into the master branch! And people see on the website! (Well, not the code. That would be weird. You know what I mean).
So what is it like, I hear mid-2014 Rabea asking. Well, let me tell you, my former self: it’s awesome. I love it.
You want me to be more specific? Here’s a typical day.
A typical day looks like this
We don’t start work until 9:30am but I usually come in earlier to do some tutorials or work on my personal projects. I have to use my own laptop at work, so it’s handy in the way that I’ve got all my code and notes with me anyway.
The others come in at some point before 9:45am which is when we have our morning stand up meeting. We’re following Agile principles for our development process and the daily 10 minute morning meeting is one of the Agile ceremonies (yes, I only recently found out that it’s really called “ceremonies"!).
My job is to create new features and enhancements and fix bugs for www.dkfindout.com{:target="_blank"}. I work together with a more experienced developer who is really, really nice and patiently answers all my questions that I fire at him on a daily basis.
At the start of a sprint we usually discuss the approach we want to take for the tasks we need to complete and divide the tasks up between us. The set up and more difficult pieces of work we usually do together - well, my colleague shows me how to do it and I try to understand the approach. And I then work by myself on easier JavaScript logic and styling.
I work on front-end code only. The website is a single page application built with Backbone.js, jQuery, SCSS, Handlebars.js templates and HTML. Data comes from a mysterious API that my manager manages. We use Git for version control and Beanstalk (kind of like Github) to store and share our code.
In good Agile fashion we have a ticket system with user stories that are written by the project managers. Each developer then assigns a story to their name and works on it until it’s done and then assigns the next story.
Lunch is at 1pm for an hour (the canteen is pretty good!) and then we usually finish around 5:30pm to 6pm. In the evenings I often go to tech meetups or do some stuff that I used to do in my pre-developer days, like going to gigs, meeting friends, going for dinner with my boyfriend, watching films. But this has been significantly reduced because my life is more or less dominated by coding at the moment. Because I'm determined to improve my developer skills and because I really, really like it.
Our sprints are three weeks long and start with sprint planning and end with a sprint presentation and retrospective.
Learnings in the first few weeks
Something that I learnt in the first couple of weeks was that there is quite a big difference between professional coding and coding your own projects for fun. For starters, there’s cross browser compatibility to worry about. When I work on this website, I use the latest CSS technologies like flex-box and don’t worry about users with old versions of Internet Explorer (what are they doing anyway? Download Chrome, for goodness sake!). I can’t really do that at work, so I had to learn how to achieve certain layouts in a bit more old school way. The floats are back in town. Urgh.
Another difference is styling a page after a design at work versus my freestyle styling that I do for personal projects. Normally I just kind of make the page look nice but if something doesn’t work the way I want it to, I just make it look a bit different if that’s easier. Not something I can do at work - it has to be exactly like the design, so I sometimes end up a lot of time on a small detail that just won’t sit right when I would normally just leave it and move on to something else. The page has to be "pixel-perfect", to quote my colleagues.
I also code in a bit more focused way. By that I mean that I don’t just go and change stuff in a million different files but work on one feature at a time. For example when I work on this website I would try to implement the blog page and then remember that I wanted to fix the header as well, so I just quickly do that and then I notice that the media queries don’t really work for the nav bar etc. At work I have to stick to one particular feature that I’m working on otherwise it just gets too messy when my colleagues need to try to understand what I’ve been doing.
Naming functions and variables is hard but it's important to do it well, so that someone will hopefully understand what they’re for. My colleague gave me the tip to try to code in a way that a developer who has never worked on this project and were to look at the code would understand what’s going on. I think that’s really good advice. I never used to be so disciplined and would sometimes even mix some German words into my method names because hey, I’m rock’n roll! But not at work. Of course.