It’s actually been closer to 18 months since my first job as a developer, but I’ve been wanting to share what I’ve learned as a newbie in the industry for a while. So although I’m late on the one-year retrospective, I think it’s worth sharing anyway.
Back in January 2015 I was laid off from my job as a labourer working for a high voltage distribution company. It was part of a long series of layoffs for me. Before that job, I had a hard time holding a job for longer than a year.
No matter how hard I worked to get hired full-time, I was always stuck in the dreadful “contractor phase” until the company experienced a slow down, and due to seniority I would be let go, and forced to find another job.
During all of this, I had decided to start learning to code in my free time. It wasn’t much at first; some nights a couple hours some other nights only 10 or 15 minutes. But I strived to learn a little bit every single day.
Even with my persistence, I simply was not able to put in the hours required to learn the landscape of the industry, on top of having basic coding skills to break into that industry which I knew nothing about at the time.
So inevitably, a couple years had gone by and I was still jumping job to job trying to make ends meet. The stress made my learning goals feel impossible at times, and for a good 6 month period while working at this high voltage company, I actually gave up.
The lay off from this company was the last draw for me. I decided that I really wanted to be a programmer and that to achieve that goal I needed to be coding and learning no less than 8-12 hours a day. My wife gave me her full support.
So that’s what I did. I went on EI (usually called unemployment benefits in the US), and instead of looking for work, I started getting back into programming – and with a vengeance too. I was hungry, hungrier than I had ever been to get out of the cycle I was caught in. I knew development was my way out, but at the time didn’t know exactly what kind of development it would be.
I started this blog as a way to document my journey from construction labourer to a full-fledged software developer. In the beginning of this journey, I was pursuing game development while learning just enough web development to get a site up and running so I could create my online presence.
Game development ended up being a hard industry to break into, and I found out it didn’t pay much either. After I joined UoPeople in pursuit of a CS degree, I met a few key people who helped encourage and guide me down the path of web development.
Once I knew what my focus was (which was the web), it didn’t take long before I got my first job offering at Khan Academy as a remote consultant; and this is where I’ll begin the real part of this story.
What I learned at KA
Working at Khan Academy was a truly amazing experience. Especially during computer science week when I got to see images and tweets of kids around the world solving challenges I helped work on. Specifically what I worked on was the HTML/CSS course, and more specifically the coding challenges on that course.
My first week of official work was one of the most stressful in my life. The way I was paid was largely an honesty system. I was to keep track of my own hours, document what I worked on and bill KA an invoice by the end of each month.
It was only supposed to be a part-time gig; 10-20 hours per week at the most. The first week I must have put in 40-50 hours (on top of completing school assignments and all of my family responsibilities) but I only billed 10!
Why?? Why would anybody do that? Maybe it was imposter syndrome, a term that’s all the rage these days, and I don’t really know what else to call it.
I was worried about my performance, and I felt like I didn’t deserve to bill every hour I worked. I felt like I wasted a lot of time understanding things that I should have understood. I was worried what they would think of me if I had billed an accurate representation of what I worked and didn’t have very much to show for it.
Eventually, I did get a little bit better at achieving a more reasonable output in fewer hours, but I was still underpaying myself. I managed to build up the courage to talk to my supervisor about what I had been doing.
Funny enough, she responds with something along the lines like “Oh, yeah for what you’re working on your hours make total sense to me”. Basically, she said to stop cheating myself and just bill whatever hours I put into the job.
The discussion was much longer than that of course, but by the end of it, my eyes had been opened. I learned something very important.
Other developers, even experienced ones, feel “imposter syndrome” (not trying to be cliche) all of the time too. It never goes away. And unfortunately, it’s this imposter syndrome that I believe is a big (not the only) part as to why it took me years instead of months to break into my first programming job.
It’s very important to remember that honesty is a virtue. That should be understood in all facets of life, but in the context of a technical career, it can be extremely frustrating for an employer or team member to be lied to.
Other than losing out on some much-needed money, nothing significantly bad happened to me because I lied at KA. However, if I had let it carry on any longer they might have thrown a lot more work and responsibility on my plate – thinking that I was more competent than I truly was. If it’s not clear, that’s a very bad thing.
So, don’t ever let yourself feel bad about what you don’t know. Just be straight about it, and ask for help if you need it. You should always be learning new things in this industry anyway, so every developer should feel like a noob with at least a few things.
Another important thing I learned while working for Khan Academy was the importance of documenting code. To be honest this was a practice that I already intuitively knew was a good thing to do. During the years of self-learning, I had experienced walking away from code for weeks and even months and then not having a clue what I was doing when I finally look back.
Good documentation helps you pick up where you left off – everyone knows this even those who are new. But once I was in the context of the real world and writing code that other developers had to read, and reading a TON of code that other developers had written there seemed to be a deeper understanding of its importance.
I had a really hard time navigating my way around sections of code that weren’t explained well with comments. Partly because I was still pretty new to JavaScript at the time. But even so, I had a good grasp on intermediate concepts and I realized how easy it was to assume that some section of your code is obvious, but really to someone who didn’t write it, it’s probably not the case.
So I’ve learned to make the habit of explaining any logic in my code. This doesn’t mean I comment every line. Explicit things like connecting to a database don’t make sense to comment and say “connecting to the database”… especially when the functions your working with literally use the terms database and connection in them.
However, explaining what you intend to do with that data after your query makes sense. Especially if there is any logic or conditions involved.
On the technical side of things, I learned a lot too. Khan Academy was my first experience working with build tools, linters, test suits and issue trackers professionally. Of course, I played with all of those things in my own time prior, but the experience of using those tools in a real world environment completely overshadows my personal use cases.
This is already getting quite longer than I expected so I won’t go into any more details about my time at Khan Academy. Instead, let’s press onward to my second programming job at Redding Designs.
What I’ve learned at Redding Designs
My job at Redding Designs is my first permanent, full-time position as a programmer. Believe it or not, I actually left Khan Academy on purpose in favour of a local(ish) web agency. It sounds crazy that I would leave a place that’s so reputable and renown for my current job as a web developer but hear me out.
Khan Academy was amazing. The pay was great, the hours were great, I had more time for my family and the work was meaningful. It also played really well with my online schooling. Having both my work and my school be 100% online was a wicked awesome lifestyle that I hope to gain back one day.
However the simple fact is that KA was contract based, and my contracts were extended by very short intervals. The longest was a 3-month contract and the shortest was 3 weeks. When you have a family to provide for, you can imagine how stressful it was.
On top of that, I also felt that it wasn’t a good career move for my first job to be remote. I was missing out on dev-to-dev conversation and feedback. I was missing out on a lot of important experiences that come from working on site along other devs, clients and managers.
And I was right. Although I took a large pay cut, had to start driving many hours a day to commute, and I’m doing less meaningful work, I’m getting way more experience now. I truly believe that if I had stuck around at Khan Academy doing the work I was doing I would not have grown as much as I have over the last 9 months at Redding Designs. Not even close.
That said, the team at Redding Designs is mostly as new, newer or not much more experienced than I am. But that’s also been a major reason why I’ve progressed so much.
Just off the top of my head, here are a few things that are a part of my daily work that I didn’t know at all before working here:
- PHP
- SQL/MySQL
- Apache
- Nginx
- WordPress (like actual WordPress development not just blogging 😉 )
- OpenCart
- Laravel (main focus these days)
- XSS and SQL injection protection
- Basic server administration
- Virtualization
- Form validation and processing
- S.O.L.I.D. principles
- Distributed Git flows
- Bitbucket
- Client communication
- Database design
And then I’ve greatly improved on skills that I had before starting here like:
- JavaScript
- CSS/SASS
- HTML 5
- Performance
- Accessibility
- Bootstrap
- Git
- Object Oriented Programming
- Wireframing
- Project planning
- Data structures and ADT’s
- Photoshop
- Time budgeting and task management
- Writing tutorials (Yeah, I make tutorials at work too)
That list isn’t exhaustive. But it’s a close representation of what my current stack looks like. It’s the result of working at a small company with only a handful of programmers.
It’s also what happens when your company has accumulated 300+ clients all with very different needs. It’s forced me to pick up a lot of technologies very quickly in order to meet the needs of varying projects. And since we don’t have a large team of programmers, often I will sort of be thrown to the wolves and it’s up to me to figure a lot of things out on my own.
This has been incredibly frustrating but it’s also been very powerful. I’ve made a lot of mistakes during the last 9 months, but I’ve made a major effort to learn from every single one.
Probably the most important skill I’ve picked up is the ability to be decisive. I tend to have a hard time deciding on what technologies to use or coming up with a price estimate when starting a fresh project. There are a lot of pros and cons to weigh against each technology, and making a decision on each piece in my stack is usually overwhelming.
But when you have a budget and timeline to stick to, decisions have to be made in a reasonable amount of time. One thing I’ve learned is that there is no best stack of technologies for any given project.
If an app, service or website becomes popular enough that your stack and design decisions really matter, then you can always build additional layers on top of the original stack. Or worst case, go back and rewrite portions of your app.
It’s also simply not always going to be possible to invest in the necessary research to figure out what tech will have the best outcome. Of course, this is in regards to relatively small projects. If I were to take on anything much larger, research would be a major part of the initial budget.
Which brings me to another acquired skill, budgeting. Both money and time. Before working at Redding Designs I had a hard time predicting how long it would take for me to build anything. At an agency, you are always taking on new projects and estimating time/costs for each project so I’ve picked up the skill quickly.
I still have a lot to learn, as I’m fairly inexperienced compared to someone in a senior position, but my ability to break projects down into features, and gauge the amount of effort required to design and implement those features has grown substantially.
9 months ago I was way off with all of my estimates (usually I underestimate), and now I feel like my estimates are spot on – at least for the relatively small scoped projects we tend to take on.
I really look forward to taking these skills up to the next level as we start moving into bigger territory with app development, and larger backend systems.
Before we do that, as a team, I believe we need to increase the quality of our work and our efficiency. I’d like to see our team use more testing (hopefully TDD or at least one of the “DD”s), adopt proper agile processes and start moving toward automated deployment strategies.
If our team can get up to speed with those skills I think our transition into larger projects is going to be pretty smooth.
And, yep. That’s pretty much it. I want to get into the habit of publishing shorter blog posts where I document my experiences and lessons as a developer. So this recap of my first year or so is like a primer for what is to come.
My thoughts is that if I post about this sort of thing more frequently I can go into greater detail about specific skills or experiences which hopefully will help other new or aspiring developers out there 😉
Cheers,
and happy holidays!
Dan
