I’ve been out of school for about three years now, two of which I’ve spent as a web developer. During those couple years I’ve learned more about programming and computer technology than I would have thought possible.
I’ve touched on countless frameworks, learned their pros and cons, and when and how to use them. I’ve become familiar with probably three times as many programming languages. I’ve become comfortable with the toolsets of various operating systems, and content management systems, and version control systems.
That’s all well and good, but my fellow developers can surely say the exact same things. It’s kind of our job right? So let’s step back from the tech here for a second and talk about something that tends to go untouched when devs talk to one another: our behavior in the workplace. Below are a few lessons I've learned during these first years.
If you're a dev, let's take a second to reflect on our actions and improve our communication with our non-technical co-workers. If you love or work with a dev, hopefully you'll understand us a little better after reading this.
We all know that feeling of grabbing a nice hot cup of coffee, putting on our favorite album (currently ZABA by Glass Animals), and getting down to business coding up that new architecture you designed. It’s relaxing, therapeutic even, building something from nothing but your thoughts; playing with mind legos.
I don’t know about you, but that is exactly why I started programming in the first place. It’s also why I occasionally have a hard time remembering that coding is only one part of my job. Since I’ve started as a web developer I’ve had to learn very quickly that there is a myriad of maintenance tasks that are every bit as important as producing the code itself. General time management, properly tracking hours, documenting processes, and communicating complex technical issues to non-technical clients are only a few that I’ve encountered.
The bottom line: It is important as a developer to always keep in mind that the world of code you are building belongs to everyone on your team. Keep them informed.
We all know some iteration of this scenario. You’re talking to Aunt Margaret over Thanksgiving and she asks you about what kind of work you do. You mention you are a web developer and explain that basically it means you make websites and apps and things. Aunt Margaret says something along the lines of “Oh you mean like Cousin Darrell.” You nod your head and agree even though you know that Cousin Darrell repairs printers for a living and knows nothing about web development. This is the curse of all of us in an IT field: it’s all the same because computers.
It’s really not that big of a deal, but one of the things this does is take away our ability as developers to complain about the mundane or frustrating things that go on at work. No one really understands what we’re talking about. So when you get a bunch of us together, inevitably the complaints fly. After all, this may be the only time of day when we are able to interact with other human beings who can actually understand and validate our problems. This is the second major point I’ve learned during my time as a developer: we like to complain and that’s ok. It’s necessary sometimes, it’s cathartic, and occasionally it even helps us put our heads together to solve an issue.
However, it's important to remember these two rules: never let complaining take the place of proper communication with coworkers or clients, and if you’re going to complain about cruddy code, you better be able to fix it.
Through my experience I’ve found one of the most universal personality traits among developers is our highly self-critical nature. We tend to have a hard time realizing that we are not, in fact, computers. We are human beings with a vast array of emotions that tend to affect our processing and cloud our judgement. Because of this, sometimes programming can be hard… like, really hard.
There will always be some combination of external and internal forces that works against you during the day. Sometimes you can’t come up with an algorithm that should be super simple. Sometimes, for the life of you, you can’t understand how that framework fits together. Sometimes you just want nothing to do with work. All of this is normal and it’s ok. These sorts of days don’t make you a bad developer, they make you a normal human being. In times like these I’ve learned that your best bet is to take a deep breath and remember that your fellow developers are there to help you. And don't forget the flip side of this: your coworkers are going to have bad days sometimes too.
At the end of the day, it's important to try your best to remain patient with each other, because after all we’re only human.
This isn’t exactly a new idea, but one that I think bears repeating. Too often I see developers (myself included) get defensive about their less-than-stellar code, or their lack of knowledge of a certain language or framework or whatever. Over these last couple years I’ve learned that ego and programming don’t go together at all.
Now I’m not suggesting the countless hours of your own time you’ve spent honing your ability to design asynchronous architectures in LOLCODE are anything to sneeze at. It’s important for all people to take pride in their work and attempt to better themselves. But probably the greatest single piece of advice I’ve heard as a developer is this: You are not your code. If you plan on staying sane in a world of constantly changing coding practices and tech, you need to be able to separate your self-worth from the code that you produced for that last project. Yes it was something you spent a lot of time on and it was born from your creativity, but guess what? Part of it kinda sucked, I guarantee it. You may not see it now, but someone else will. Heck, that someone might even be you a year or so into the future.
The key to becoming the best version of your developer self: You are inevitably biased towards your own design. Realize this and embrace it. Show your work to others, take criticism, fix it, learn, move on.
These are just a few of the lessons I've learned in a few short years as a developer. They've helped me (and my teammates) stay sane in the crazy world of web development.
If you want to work with a group of team players, give us a shout.
Want to make a good first impression? Pay attention to your homepage (your users already are!). Here are some tips for great homepage design.
How do you make a minimum viable product that gets all parties' buy-in? You prototype. See why prototypes are a required step in app design.