6 Ways to Quantify Your Code - and Why You Need to Do It
Join the DZone community and get the full member experience.Join For Free
originally written by
at the new relic blog.
businesspeople dig numbers. they don’t necessarily want to hear that you got something done; they want to hear how much you got done—especially relative to past results or some other relevant benchmark—and they want to know the value of what you did.
some professionals have it easy when it comes to quantifying their job performance. salespeople can measure their achievements in dollars and cents, for example, and many other fields also have clear-cut numbers with which to calculate their contributions.
for software developers and some other technology-based roles, however, quantifying your work can be a struggle without a straightforward solution. yet doing so is crucial not just in job searches, but in many aspects of a software engineer’s career: performance reviews, effectively communicating up the chain of command, working efficiently with non-technical business units, and ensuring you’re properly valued within your organization.
so how do you measure the value of the applications you build, scale, monitor, test, and otherwise support? here are some of the approaches used at new relic, as well as industry best practices:
“i like to see work accomplishments described in terms of situation, action and results,” says merilee krebs, a technical recruiter at new relic. “what was the business or technical problem to be solved? what unique actions did you take to resolve them and what was the resulting improvement.”
what does that look like in the real world? try asking yourself some pointed questions: did your monitoring and testing lead to a code update that cut down on help desk tickets by x percent? that’s quantitative gold right there. did you deliver a new app six weeks ahead of schedule? yeah, you’ll want to brag about that (in a professional manner, of course). can you connect your code to strategic company objectives? please, do so. are you doing something that’s outperforming the traditional standards in your industry? you should be able to quantify the achievement is some way.
if this exercise feels unnatural to you, you’re not alone—many programmers often aren’t born sales and marketing pros. if they were, they’d probably work in sales or marketing. so let’s consider six ways to better measure and communicate the value of your code and related work.
1. think in percentages
programmers might not always be able to point directly to numbers like revenue or profits, but that doesn’t mean you can’t put a number on your performance. instead of dollar signs, think in terms of percentage signs.
“i like to see percentages of change, such as the percentage of performance improvement before and after the project,” krebs said. “what difference or impact did your actions and abilities make? was there a measurable improvement before and after? if so, share that in percentages or another numerical quantification.”
2. get involved with open source projects
tom hart, coo and cmo of the tech recruiting firm eliassen group , recommends open source projects as a natural way for developers and related roles to not only build marketable skills, but to build a quantifiable track record with those skills—and build the habit of measuring your work as you go.
“participation in open source projects allows you to interact with your peers, get feedback on your work, and be incessantly evaluated for your ideas and skills,” hart said. “for employers seeking candidates, these groups are an excellent way to evaluate someone’s coding skills, because the work that is being submitted or posted is always being dissected by other programmers.”
hart recommends the open-source organizations free software foundation , the open knowledge foundation , and the open source initiative as places to look for opportunities to get involved. check out our blog posts on what makes a great open source contribution and the essential traits of a great open source contributor, too.
sharing technical knowledge widely also helps. having an active github profile, spreading industry knowledge on social media, speaking at conferences or tech meetups demonstrates passion and commitment.
3. measure progress, not just products
it’s not always about the finished product—progress counts, too, especially in the growing world of devops and agile development methodologies where change is constant and applications are almost never “done” in the traditional sense. that should influence how you measure and report on your work.
at a list apart , eileen webb recounts the potential misconceptions that arise when clients and other stakeholders can’t necessarily “see” the progress being made on a particular project—even as the most grueling code calisthenics occur behind the scenes.
to cope, webb adjusted milestone communications to prioritize “visual issues”—the kinds of code changes that resulted in front-end interface changes that everyone on the team could see. “by strategically addressing the visually obvious issues, we created an external sense of progress for our stakeholders that was a more accurate reflection of the amount of work going into the code,” webb writes.
4. keep a work journal
don’t worry, it’s not “dear diary” time. but if you want to capture the value you and your applications provide, you’re going to need some way to track your efforts. in his website series leveling up , veteran software developer peter lyons says it can be as simple as a single .txt file—he posts an example to his site—but you need some record of what you do so that you can give status updates to mangers, ensure you’re covering all bases in a performance review, and combat natural memory.
5. communicate in two languages
lyons also suggests a two-part format when sending email updates to management, team members, and other stakeholders, especially when the audience includes non-technical management: first, explain the accomplishment or news in plain terms while avoiding technical explanations or jargon. second, supply technical details for those that want them and can understand them. everyone else can stop reading, and you haven’t wasted their time.
6. collect recommendations
another way developers can quantify their accomplishments is to encourage others to do it for them. if you get recognized for specific skills and accomplishments, make sure that you share those recommendations. krebs notes that linkedin can be a good tool for collecting and communicating this kind of feedback. “if there’s something that multiple people have mentioned that you do great, write something in your role description like “consistently recognized by colleagues for x ,” she says, or even share specific numbers and comments.
finally, remember that even the best numbers rarely capture the entire picture of a programmer’s professional value. when applying for a job, spend some time crafting a personalized cover letter. “our hiring managers read and consider cover letters as a key part of applications,” concludes krebs. “at new relic, many of our job postings even ask for specific questions to be addressed in the cover letter.”
Published at DZone with permission of Fredric Paul, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
WireMock: The Ridiculously Easy Way (For Spring Microservices)
Five Java Books Beginners and Professionals Should Read
VPN Architecture for Internal Networks
Designing a New Framework for Ephemeral Resources