by Frances Advincula I am terribly lucky to have a lot of mentors, especially on the team that I am in. They are literally taking the …
by Frances Advincula
I am terribly lucky to have a lot of mentors, especially on the team that I am in. They are literally taking the adage “It takes a village to raise a child” to heart. Sadly for us, one of my mentors is leaving the team today in pursuit of other adventures in engineering land. The way the team started to mourn his decision really struck a chord in me. What made him so loved?
I realized that he was not just a programmer — he was a software developer. And I want to grow up to be just like him.
(See how sweet he is?)
According to Erick Sink, here is the difference between the two.
…a “programmer” is someone who does nothing but code new features and [if you’re lucky] fix bugs. They don’t write specs. They don’t write automated test cases. They don’t help keep the automated build system up to date. They don’t help customers work out tough problems. They don’t help write documentation. They don’t help with testing. They don’t even read code. All they do is write new code. In a small ISV, you don’t want any of these people in your company.
Instead of “programmers” (people that specialize in writing code), what you need are “developers” (people who will contribute in multiple ways to make the product successful).
Thus, as part of my goals for 2013, and inspired by my many mentors, I want to be more helpful to my team throughout the entire process, always keeping in mind that great products provide seamless experiences from end-to-end. That includes everything and involves a lot of people! Here are a few reminders I wrote up for myself.
For UX
1. Suggest things that you think will improve the user experience, but realize that the UX team is the expert in the subject. They breathe this stuff. Their work goes above and beyond colors and graphics; they put real research into their work to make sure the needs of customers get met in the best way possible.
2. Work closely with them if you are in the front end, and make sure to do so from the beginning. That way, there is less re-work, unlike if you start coding already and visions end up not aligning. Also, because they may be fully aware of what is technically possible or not, make sure you understand the goals behind their design. That way, if you are not agreeing with something, you can suggest something similar that satisfies that goal.
For Documentation
1. Realize that the doc team may not necessarily speak the same techie mumbo jumbo as you. Make sure that you write good notes for your task in your project management tool. Remember that as the doc team writes release notes for customers, they are usually concerned about tangible changes that should affect what the customer sees. Write your notes accordingly.
2. Although it deserves another post on its own, never ever make them feel like they are “just doc.” Great documentation is one of those things that go unnoticed when it is really good, but are blatantly annoying when they are bad.
For Managers (Scrum Master, Project Manager, Product Owner, etc.)
1. Know their style. Some love to be emailed (so they can avoid meetings), and some love meetings (so they don’t drown in a sea of emails). Work with it.
2. Remember that managers always push for more — that is their job. Therefore, if you cannot do something, speak up. They would rather you say “no” than just keep saying “yes” and not deliver.
3. Stop whining about meetings; instead, make sure you really need to be there and take responsibility for making it productive.
For Software Architects/Other Developers
1. Write more functional specs and touch base often. That way, more senior engineers can tell you that you are going down the wrong rabbit hole before you write a lot of code.
2. If you are touching their code, especially as a newbie, let them know/ask for a code review before you commit. Of course they will see it in the commit logs, but I like to do this out of respect and to make sure the best code possible is committed.
3. Be obsessed about your code and take pride in it. Think about all the ways users can and will interact with it. Brainstorm. Really think about what you are building. Write unit tests, because they force you to really think about the requirements and what goes in — and it’s virtually impossible to unit test bad code, BUT do not rely on them as a silver bullet. Just because the unit test passed doesn’t mean the code is great. (Thank you to my other awesome mentor, Mr. J, for your great advice. I still don’t know how you put up with me!)
4. Don’t forget to spend time coding what you love, no matter how little time it is. A wise man told me that this is the difference between awesome developers and regular developers, for it will keep your passion roaring!
For QA
1. Depending on your organization and team, realize that some QA are super techie and some aren’t. Make sure that you communicate on their terms. Be sure you are clear about what your code changes will affect, in case they need to test more things than what is currently your task/unit of work.
2. Be patient with all their nitty-gritty questions. Those questions force you to think about what your code does in new ways, and will more closely mimic questions that your customers will potentially ask.
For Release Management/Dev Ops
1. Find out what they need to know from you when you commit. For instance, on some branches in SVN, if I commit, the RM needs to know if I added or deleted files; otherwise, the installs break.
2. If your commit breaks the build, fix it as soon as possible. If you like to commit a lot at the end of the day, wait for a successful build before you go home.
In a nutshell, good software developers don’t just write code. We work hand-in-hand with a lot of people to ensure that the code we write turns into a great product that makes people happy, real happy.
Frances Advincula writes the series Frances Fridays. Frances recently graduated with a degree in Computer Science with specialization in Software Engineering. She now works as a Software Developer for Accenture (Software). A proud geek girl, she’s sure she is the only one who can’t play video games. Follow her random musings at @FranAdvincula.
