Andy Stitt

Posted on Feb 27, 2020

10 lessons learned on a 12-year journey as a web developer

#webdev #beginners #career

Hi, I'm Andy. I started working with websites in 2008, and I've been a full-time professional developer since June 2016.

I started my career in the nonprofit field as an office assistant and then program administrator. I had experimented with website building as a bored teenager in the 90's. I re-discovered an interest in websites in 2008 when I got the opportunity to manage my organization's website.

Since then, I have devoured knowledge on marketing, project management, and web development. I got an MBA in marketing and two project management certifications along the way.

In June 2016, I started my own WordPress freelance business and thus my career as a full-time professional developer. I closed up shop after seven months due to financial instability.

Since then, I have managed to make a living as a full-time and short-term/long-term contract web developer.

I've had many ups, downs, and lessons learned in my journey as someone who switched to web development from not having a computer science background. Here's what I learned:

1. This profession is difficult.

Web development is complex, and it's absolutely impossible to know every single thing.

I've gone to many, many meetups and conferences where I don't understand what on earth people are talking about in terms of programming. I'm a front-end guy, so I can only assume that whatever they were talking about was back-end or server stuff.

Even though I'm a front-end guy, whenever I go to my local React meetup and they talk about pretty much anything, I still have no idea what's going on.

You'll experience this too. It's ok. Things will become more apparent over time

2. Get a mentor

If I had a mentor, then I probably would've cut my learning curve by quite a lot. It's incredibly difficult for me to reach out for help. I experienced early childhood trauma, so I have unconsciously thought that:

It would be unsafe to ask for help
If I had to ask for help, then it would show that I wasn't good enough

I still don't have a mentor and am making it a priority to find one this year.

3. Empathy is your greatest quality.

Solving complex problems and writing code that works might give you great satisfaction. Hopefully you also find fulfillment in building products that improve people's lives.

In my current gig, I help build websites that move government forward and make it more accessible to its constituents. Previous jobs have allowed me to build websites that:

Connect people to their Judaism through education, volunteering, community and philanthropy
Connect college students to scholarships
Connect school teachers to resources that help them teach their students life skills via learning through projects

My entire career has been about "tech for good" and building programs that help people. This makes my career not only fun because of problem solving and piecing together puzzles, but also rewarding.

4. Problem-solving is your second-greatest quality

In my journey as a developer, I have used the following technologies, frameworks, and content management systems (and am probably forgetting a few):

HTML
CSS
Sass
JavaScript
jQuery
GreenSock
React
NodeJS
PHP
ASP
Visual Basic (for automating Microsoft Excel tasks)
SQL
GraphQL
Bootstrap
Foundation
WordPress
ExpressionEngine
MojoMotor
Sitecore
Drupal
Gatsby

This in no way makes me a ninja or a rockstar. It simply means that a whole bunch of tools accomplish essentially the same thing.

You don't have to be a PHP developer, JavaScript developer, or any one thing developer. You can be a web developer. One that can take a set of tools and learn how to use them through reading documentation and then trial and error.

5. Don't be afraid to work on both sides of the stack

It's perfectly ok to specialize in front-end or back-end. It's good for your career since they are two different disciplines.

However, the task at hand may require you to work on both sides of the stack.

I first experienced this when I managed my first website in 2008. It was built in static HTML, but it used server-side includes so that you only had to change one file for the header, one file for the sidebar, and one file for the footer on all pages.

These includes were written in classic ASP, which is a back-end language.

I then experienced this working with WordPress. It is a content management system built on PHP. So, in certain instances, when I wanted a particular result on the front-end, I wrote PHP to make it happen.

In a recent contract job I had, websites that were not built on a content management system made extensive use of PHP for server-side includes and other functionality.

I'm a front-end developer, but when the task called for working on the back-end of the stack, I was able to do it.

As a bonus, you can also learn about databases for when you're using a content management system that has content stored in a database.

6. You don't have to be a guru/ninja/rockstar

You don't have to know sixteen different languages, have 20 years of experience with React (especially when React isn't nearly that old), know everything about servers, and be an expert at cybersecurity.

Anyone who is asking for an unusually long list of competencies is trying to overwork you and underpay you.

For those job descriptions that have a more reasonable list of expectations, you don't have to know everything on those either. You have to know enough of the core requirements and be willing and excited to learn how to do the others.

7. Build real applications as often as possible

They don't have to be complex applications. It can be a to-do list or a pounds to kilograms converter in JavaScript. It can be a portfolio website in pure HTML and CSS.

I have taken ten million online courses/tutorials on languages, and I wondered why I wasn't becoming a better developer. I could write variables, arrays, and if statements in several different languages.

What I wasn't getting better at was developing websites and applications.

When you develop software, you have a set of requirements that you want it to accomplish. Then you decide the best tool for the job to get it to accomplish those requirements (language, framework, CMS, etc.).

Once you make that decision, then you plan how you're going to use that tool to build the functionality. Then you write code. Then you test it and fix whatever bugs come about from it.

This is how you get better at web development. Not by taking tutorials to learn as many languages as possible like I did.

8. Learn the foundations of web development: HTML, CSS and JavaScript

There are 1,000,000 different tools, frameworks, languages, etc. that you can use to build websites. However, the browser still renders HTML, CSS and JavaScript.

HTML tells the browser what to put on the screen. CSS tells the browser how it should appear (color, height, width, which font, etc.). JavaScript adds interactivity (though CSS does sometimes too, but that's not its primary role).

When you learn the foundations first, then it will be much easier for everything else to make sense.

I've worked quite a bit with jQuery and have dabbled in React. However, things started making much more sense once I started learning vanilla JavaScript.

9. Get a code editor that helps you

A code editor that can find mistakes as you're writing code will save you a ton of time.

If you use a code editor that doesn't do that, and something breaks, then you'll have to spend time tracking down the culprit. Depending on how much code has been written and what dependencies there are, it could take a while.

Code editors that can incorporate CSS and JavaScript linters as well as other tools that point out mistakes are invaluable.

10. Give yourself a break for being human.

You won't know everything right off the bat. You won't learn everything in a short time.

You'll make mistakes. Others will point out your mistakes.

You'll want to go to more networking events and conferences and then get tired of being so social.

Go forth

My journey has been extraordinary. It has been filled with ups and downs.

When I was a full-time freelancer, I ran around my living room shouting with joy when a team member committed my code to the master branch of the Git repository.

One month later, the company decided not to retain my contract, my income dropped to zero, and I drove myself to the hospital crisis center because my anxiety spiked out of control.

Two months later, I took over the role of technical project manager and helped launch a redesigned WordPress website in three months while simultaneously migrating email systems. I then got to be the lead developer and got to develop on WordPress, Foundation, and HubSpot.

2.5 years later, I got laid off and was able to quickly pick up a short-term contract building websites, emails, and banner ads for a pharma marketing agency.

Four months later, I'm diving into the world of website building for state government.

I've gotten to meet all kinds of people, build all kinds of cool things, and have lots of fun despite the headaches at my 9-5. My adaptability, experience, connections, and knowledge of how the game is played have allowed me to rebound from adversity very well.

If all of this sounds like your thing, then go forth!

Top comments (22)

kethmars • Feb 29 '20 • Edited

Great article, great points. I really liked the honesty but also applicable tips.

// edit: Based on your journey, do you have any advice regarding code quality? Especially when you transformed from a part-timer/freelancer to full-time professional? How did the transitsion impact the quality of your work?

Andy Stitt • Feb 29 '20

Thank you! That’s an interesting question re: code quality. In the early part of my journey, I was happy with code that worked! When I was solo, I tried writing code as efficiently as possible with not writing too many lines of code and trying to gain as much of a performance edge as possible.

Since I’ve started working with teams, I try to make my code as readable as possible. Even if it isn’t perfectly efficient or not perfectly performant. Writing readable code allows my teammates and future employees to understand it, maintain it, and build on it.