Writing code can be seen through many lenses, but for those who love it most, it’s often described as a kind of artform — a blend of hard engineering and genuine creativity that ends up telling a computer what you want it to do.
To be good at coding, you need to have a blend of ingenuity, patience and technical analysis that can be hard to come across. Perhaps that’s part of the reason why employees with coding skills are in such high demand across industries. Here, we’ve caught up with a few Boston techies to better understand why they learned to code and why they love doing it for a living.
Responses from Kit Thompson, Senior UX Developer at Toast 
What's your job?
I am a front-end engineer with a focus on HTML, CSS and Javascript. I help make our online ordering platform even better for our customers and their guests. In essence, I work on build systems and make things pretty.
What made you want to be a developer?
In high school, I was really into robotics and got involved in robotic competitions. I found a passion for control systems and making them easier to use. So this put me down a path of helping to make products that benefit the end-user.
What skills are necessary to being a good dev?
Patience and logic are crucial. This helps you become good at solving problems. A passion for computers is pretty important too. And guess what — sometimes I actually use trigonometry! Knowing a little bit about math doesn’t hurt.
How did you learn to code?
I began as self-taught. I first started coding on my TI-83 calculator in high school. I wrote a game that would help you solve quadratic equations. I later went on to take programming classes and was formally trained at Rensselaer Polytechnic Institute.
What advice would you give someone thinking about learning to code?
Learning to code is great, but wanting to do something with code is even better; this goes back to having a passion. I find this helps drive focus and engagement as you are slogging through various techniques. Think about coding in the same way you would think about learning guitar — you can take classes and learn theory, but sometimes just playing along with a song on the radio is better.
I also think it is important to get involved in the coding community; check out sites like meetup.com to find your local coding group. Treehouse and Codecademy are also good places to learn more.
What is your favorite part about your job?
I like the pace of Toast — we push out new features almost every week and get to see people actually using the product. It’s rewarding.
What is the most challenging part of your job? How do you overcome it?
Resisting the awesome snacks and lunches that we always have in our kitchen here at Toast. Right now, there's a 10-pound box of chocolate truffles taunting all of us. We tried overcoming this very pressing challenge by dumping a bunch of them on our co-founder’s desk, but it didn’t even make a dent.
Responses from Josh Puetz, Senior Software Engineer at Codeship 
What's your job?
I work with our product team to add new features to the Codeship website. That could be anything from making it easier for users to manage their accounts to viewing their build runs. As a new member of the team, a large part of my job recently has been to ask questions and provide an outsider’s perspective to our development practices.
What made you want to be a developer?
I’ve always been fascinated with computers. In elementary school growing up, we had one hour of computer time every week. I convinced my mom to volunteer to be the ‘computer room parent’ so I could sneak in after school and play on the computers more.
In fourth grade the uncle of one of my classmates came to school to tell us about this job. He worked on CAD tools at the local factory, and he brought his brand new Macintosh from work to show us the kind of things he did all day long. It was the first time I had been exposed to the idea that computers could be tools as well as learning and entertainment devices.
What skills are necessary to being a good dev?
More than anything, the desire to learn and teach yourself. As a software developer you’ll often be trying to solve a problem, and the ability to research and learn are critical to finding answers.
The other critical skill for a developer is empathy; rarely are you writing code all by yourself. You’ll be interacting with many people including other developers, your customers and your business owners. Listening and understanding other people is critical to undemanding the problems you’re trying to solve.
How did you learn to code?
I took a summer school class in 6th grade where we learned how to write programs in Logo, a language where you use commands to make drawings. I took a few more summer programs and had my first actual coding class in high school.
What advice would you give someone thinking about learning to code?
Start out small and just do it! There are so many amazing and free resources today to learning coding: Hour of Code has some wonderful tutorials to get started.
Find a community — a friend who already is an engineer, a study group or an online forum is a great way to keep yourself motivated when the going gets tough (and it WILL get tough!)
What is your favorite part about your job?
The satisfaction of working through a challenging problem, finding a solution and seeing it work. Almost 20 years into my career and it still hasn’t gotten old!
What is the most challenging part of your job? How do you overcome it?
Work/life balance — there’s never a point at which my work is done. I’ll never open up my laptop and see that everything has been accomplished and I have an empty to-do list. There is always a bug to fix, and improvement to be made and a new feature to implement. It’s tempting to try to work as hard as possible for as long as possible in the hopes of getting everything done, but it’s just not going to happen. Instead, I have to work to conserve my energy and attention. That means I eat well, exercise and take time off to spend with my family. The code will always be there then I get back.
Responses from Ben Jackson, Software Engineer at ezCater 
What's your job?
As a software engineer at ezCater, I help with building new programs, maintaining and improving code, hiring and team building with our growing team of engineers and planning for future projects.
What made you want to be a developer?
I've always had an insatiable curiosity for programming. Growing up, I gravitated toward computers, tinkering with things and playing around in QBasic, a beginner’s guide to code. I took two years of Computer Science in high school, then headed to college to pursue an engineering degree. Along the way, my interests started to shift from computers to cooking, so I left the engineering world and spent the next 10 years working in restaurants and learning about all things food. Eventually, I left the restaurant world and joined a small startup on a whim. Then pretty much by accident, I re-discovered my passion for coding while on the job, and everything just took off from there. ezCater kind of marries my love for food and engineering — it's like a nerdy rom-com.
What skills are necessary to being a good dev?
Being a good listener and always pushing yourself to learn and improve are vital to being a good developer. The ability to honestly evaluate yourself and your work in hindsight, is hard to do but can be very humbling. Always do this — no matter where you're at in a project, your career or in your life. Having a sense of humor doesn’t hurt, either.
How did you learn to code?
I've been learning through osmosis over the past four years at ezCater. Being around smart, talented people is the best education you could ask for. I try to educate myself outside of work by reading programming books, articles and blogs. I read other people’s code and have them read mine. Every time something happens in code that makes me go, "Huh? Well, that was weird,” I'll go down the rabbit hole to figure out exactly what happened and why. That mindset has helped me out a lot.
What advice would you give someone thinking about learning to code?
Do it! Surround yourself with people who know more than you do. You should feel like you're in just a little bit over your head most of the time. It will help get you out of your comfort zone and grow. Read a lot, and not just about programming languages, learn Vim and get enough sleep.
What is your favorite part about your job?
I love seeing the things I've worked on being used by people out there in the world. It's surreal. I love that I can learn constantly, keep my interests fed and still call it 'work.’ Also, not leaving work at 2 a.m. every night has also been nice.
What is the most challenging part of your job? How do you overcome it?
When things break, as they're bound to do at some point, it's difficult to not take that personally. I've come to realize that those moments are the best times to learn, which has helped me out a lot in my career. Being able to take a step back, evaluate things, and find a better way forward is a skill that takes practice. Just hopefully not too much practice because we still need the website to work!
Responses from Madison May, CTO at indico 
What's your job?
I'm CTO at indico data solutions, a Boston-area startup building a toolkit to enable developers to extract quantitative information from qualitative data sources (text and image data). On any given day, I might be doing anything from developer operations work (updating the tools that we use to keep our servers up and running), to machine learning work (translating a customer's problem into a format appropriate for a data science solution), to traditional backend engineering work (writing the core API infrastructure that exposes our APIs via RESTful endpoints).
What made you want to be a developer?
When I applied to college I fully intended to end up as a mechanical engineer. I taught myself to code the summer after my last high school year, initially because I thought I would be behind my peers in college if I started college without any software experience. But what started as an attempt to not fall behind the curve ended as an obsession for all things software. Something about the quick turnaround time from idea to reality in the world of software clicked with me. The instant gratification of software experimentation had me hooked.
What skills are necessary to being a good dev?
I've come to believe that writing good software is more akin to traditional writing than you might think. Software is fundamentally a communication problem, with two intended audiences — the first being a compiler/interpreter, and the second being anyone who might need to read, understand, or modify your code down the road. Traditional computer science programs produce students who are well equipped to write software for the first audience — the compiler/interpreter. Fewer programs produce students who are well prepared to write software for the human beings who will read your code.
How did you learn to code?
I first learned to code by reading Allen Downey's book, Think Python: How to Think Like a Computer Scientist, and by taking some of the first software courses published on the Udacity platform. I picked up more fundamentals from coursework at Olin College and from the maintainers of the CPython project who were kind enough to introduce me to the process of contributing to the open source community.
What advice would you give someone thinking about learning to code?
- A surprisingly small amount of programming is typing — make sure to spend time planning out the structure of your code before you start clacking away on your keyboard.
- Stand on the shoulders of giants — don't reinvent the wheel if there is a pre-existing solution that is a good fit for your problem.
- Optimize for quick experimentation — if it ever becomes time consuming to test a hypothesis about how your code functions, spend time thinking how you can modify your workflow to make testing your understanding of the code easier.
- Find more experienced developers and ask them to review your code — always be open to critique.
- Get experience writing software in a group setting. Because so much of software is communication, it's critical that you don't always work solo.
- Build something useful and real — coding is so much more satisfying when you're not solving artificial problems.
What is your favorite part about your job?
The people I have the pleasure of working with. Every person at indico has expertise in their own area, and I'm constantly learning from the folks around me. They're friends and peers first and foremost, coworkers second. When you're surrounded by friendly people you respect and know you can learn from, even the most mundane tasks can be enjoyable. I never look forward to updating our PHP and R client libraries, but having a group of people I can commiserate with makes the prospect much more entertaining.
What is the most challenging part of your job? How do you overcome it?
Although not specific to my job, I think quite a few problems in software arise when the goals of a project slowly shift, and the codebase fails to shift with it. Let's call this "code drift." Say you're working on a project team that has built a handy piece of software to solve "Problem A." You've demoed your software to potential customers, and they've communicated that although solving "Problem A" is nice, their biggest pain point is a related problem, "Problem B." Now "Problem B" is pretty similar to "Problem A," and you've spent quite a bit of time solving "Problem A," so you reason that you might as well reuse your code from "Problem A" to solve "Problem B." Seems reasonable, right? After all, effective software engineering is all about code reuse. However, what happens in practice is that the project often becomes a veritable Frankenstein solution of "Problem A" and "Problem B." In trying to prevent the deletion of "good code," your project team has failed to realize that "Problem B" has a different set of concerns than "Problem A," and that adapting your "Problem A" code to solve "Problem B" may lead to a mediocre end solution. I would hazard a guess that this problem is exceedingly common in the startup community, where you're constantly revising your pitch and your view of the problem that your end customer has. Don't be afraid to delete code when it makes sense. On my most productive days I delete more code than I write. Don't be afraid to start from a clean slate if you recognize that your existing code isn't a good fit for a revised problem statement.
Photos via companies
Is there a rockstar coder at your tech company? Let us know or tweet us @BuiltInBOS
 copy 2.png)
