Natalie Kozlowski is a front-end web developer at CodeGuard. She's a self-taught coder who embraces open source and will be giving a talk about how to interact with your front-end developers at this year's All Things Open conference in Raleigh.
In this interview, I caught up with Natalie prior to the conference. I learned more about her background, like how she earned a degree in Professional Writing, what led her to her current job as a front-end developer, and how she applies the open source way to her job.
Can you tell us a bit about yourself and your background?
I graduated from Michigan State University with a bachelors in Professional Writing. After graduating I moved to Atlanta, GA to work at CodeGuard as their front-end web developer. CodeGuard is a website backup, monitoring, and restore service for the web. As the front-end developer, I not only oversee all of the front-end code for the application but also all of our design needs.
As far as design goes, I’ve learned to love a wide variety of activities. I started out in Photoshop creating web designs and interface designs, and from there I expanded to learning Illustrator to create custom logos and icons for my work. After that, I branched out further and came to love aspects of print design as well, for example T-shirt design, infographic design, poster design, digital comic illustrations, and so much more. Even today, I still enter T-shirt design competitions in my down time, just for fun!
I also enjoy a very wide variety of development disciplines. I’ve been able to work on projects in PHP, Node.js, Ruby, and of course every front-end framework/library/language/pre-processor I can get my hands on! I love learning new technologies and enjoy challenging myself with new tools I’ve never used before. I see front-end development as a balance between two things that I love: design and development.
A few high-profile projects that I’ve worked on at CodeGuard include the re-design of our homepage, the mobile optimization of our homepage, and also the designs for our company T-shirts.
Outside of work, I enjoy being active by hiking and biking around Atlanta. Other hobbies of mine include playing percussion in a community band and learning to speak Korean.
As a graduate in professional writing, what led you to become a front-end developer?
You wouldn’t believe how often I get asked this! It’s a question I love answering though.
Within the Professional Writing major at Michigan State University you can choose to specialize in one of three tracks. I choose the Digital & Technical Writing track, which helped give me a small understanding of code (mostly HTML/CSS), a good understanding of web design best-practices, and a great understanding of how to write for the web and how to focus on the digital rhetoric of what it is you’re creating. Basically my major focused on what is most important when it comes to websites: content. Another name for my major and specialization at the time could have been “User Experience Design.”
I loved my major, but at the same time I found myself drawn to coding and development more and more. I heavily valued the UX and writing skills I was learning in my major, so instead of switching majors to something like Computer Science I self-taught myself to code through free online resources and web development internships/student jobs that I landed as an undergrad.
By the end of my senior year, I definitely identified myself more as a ‘back-end’ developer, but I was still very interested in web design and interested in using the graphic design skills my major taught. In the end, front-end development was a great balance for me between my love for designing and my love for coding. Front-end development lets me be technical and nerd-out when I want to, while also allowing me to care about the user experience and the aesthetic of the thing I’m creating. At this point I don’t think I could really choose one discipline over the other anymore (to be only a web/UI/UX designer or only a web developer). I love that front-end development lets me do both!
So to answer the question: I think that my major did prepare me to be a front-end developer, though it also took a lot of self-teaching and drive along the way to mold myself into the professional I wanted to be. Not everyone sees the connection of my education to my career at first, but after I explain my journey through school most people come to understand how I got to where I am today.
I definitely think that open source technologies are what made my self-education of development possible. I think that being able to experiment with open source projects and libraries as a young student was crucial for me in becoming who I am today. Without that exposure, or that access to the development world, I probably would have given up out of frustration thinking the barrier-to-entry was too high or over my head! I'm grateful that I was able to discover the open source world.
Development is at the core of open source projects. What could these teams, often decentralized and self-organizing, learn from your experience leading a development team?
I would say communication is the key to success for any development project. Every morning at 10am all of the developers at CodeGuard gather around for a morning scrum where we talk about what we worked on yesterday, what we plan to work on today, and what any development blockers to our work might be.
These short 15-minute long meetings have greatly helped our process. For example, my coworker Jonathan and I may not ever work on the same part of a feature while the team builds something, but understanding how his part of the code works is still incredibly valuable for me. A time may come in the future when I need to modify parts of his code, or add to it, and having a good understanding of what he built will save me a lot of time in the future, or for any developer that works on that feature.
We also rely on GitHub Issues and GitHub Pull Requests heavily when it comes to checking in new code and reviewing each other’s work. The comment system inside GitHub has become a place where a lot of communication happens for the team, and a place where we resolve a lot of problems.
As a team, we are also a very chatty group. I don’t mean to say we’re constantly having conversations out loud in the office, but we do use a group-chat service called HipChat that serves as the hub for all of our system’s alerts and most of our team discussions throughout the day. We have a separate chat room for our developer conversations, for our support discussions, for the code we are committing, and more. We even have a separate chat room to discuss the temperature of the office, in case anyone wants the thermostat to be turned up or down. That last one is a bit silly, even we realize that, but what I’m trying to stress is that we communicate a lot, and we use multiple services/platforms to do it. We often have parts of the team working remotely too, so keeping everyone up to speed is crucial for us. Our daily morning scrums definitely help, along with the array of other tools we use. If a team member is remote for the day, we make sure to video call them in for our scrums!
The open source way is about open exchange, rapid prototyping, and participation. Do you apply these characteristics yourself, in your daily work and collaboration with back-end developers? Do you benefit from them?
I think that I do embrace these characteristics. Most of the companies I’ve worked at practice agile development, so I’m used to fast paced environments where getting out an “MVP (Minimum Viable Product)” and then iterating is the way things are done. We do a lot of pair-programming at CodeGuard as well. Being the only front-end developer means I’m always pairing with a back-end developer. I like to think we’ve found a good way to work together, share knowledge, and collaborate effectively. It comes with practice!
Even when I’m not pairing I still interact with the back-end guys quite a bit. I think that work environments that promote this type of interaction (designers working closely with back-end developers, front-end developers working closely with back-end developers, developers working closely with sales teams, or marketing teams, etc.) will end up producing a stronger product. I think this is true because each part of the team ends up getting exposure to the other working parts of the team much more than they would if they were isolated to their roles. I think having a better understanding of the other roles on the team can make work more efficient in the long run. So any team can benefit from this!
Can you share an example of a user experience or web application you (and your team) built, based on open source?
We definitely embrace open source technology at CodeGuard. Our main application is built using Ruby on Rails, and we use many other open source technologies to hold everything together.
One of our developers wrote a tool called s3goph3r in Go for streaming things concurrently to Amazon S3. We use Amazon S3 for storing all of our backups, and what he created was a much-needed solution for a problem we were having at CodeGuard. He open sourced the project on GitHub, and so far the community has responded pretty positively to it! People have even started downloading it and contributing to the codebase. It was the first time he open sourced something, and I remember him jokingly saying he wasn’t sure how he felt about someone submitting their first pull-request for his project!
Any final words? A sneak peek into your talk or tip for open source developers?
My talk is really about team communication and how back-end developers and front-end developers can best work together on a project to keep everyone happy and deadlines met. I mentioned above how important I think good communication is on a development project. I’ll definitely be going in-depth into all of this during my talk!
I’ll be giving my perspective on the topic from a position of being a front-end developer but also a designer. I think that any developer could benefit from hearing this talk, whether you're working on an open source project, a private project, you write Ruby code, or Perl code, or Lisp, etc. I’ve talked with enough developers to know that in some workplaces developers and designers are seriously segregated. As in, no interaction happens at all!
My talk goes into why I think we’re doing ourselves and our product an injustice by doing that, but also about how people can start to improve this at their workplace.
See the full series of All Things Open 2014 speaker interviews.
Comments are closed.