Do Ninja Coders Write in Invisible Ink?

The following is a copy of a post I authored for Scouted – see the original over at the Scouted blog.

***

Calling all talented technologists!  All dabblers of data!  All muddlers of math!  Can you curry lambda calculus problems with ease?  Could you A* your way out of a friggin’ maze!?  Do you dream in oh-so-glorious-code!!?  If so, we want you, oh prophetic rockstar programmer ninja warrior!

ninja coding

When it comes to jobs that deal with software, there are big inconsistencies with titles.  A dentist is a dentist, but for tech-folks, there are programmers, coders, developers, engineers, hackers, and indeed, rockstars, ninjas, jedis, and warriors.  

While different companies may each have their own interpretation of “software developer,” all of these labels boil to the same primary functional responsibility: build stuff in code, turn 0s into 1s, and, basically, get stuff done.

That said, “build stuff in code” is a broad charge.  There is a spectrum of effort in building stuff and no shortage of ways to work in code.  Many argue there’s a taxonomy across some of these titles: programmers and coders focus on writing code whereas developers and engineers focus on thinking about code; a rockstar is passionate and creative while a ninja is disciplined and efficient.  (Note that many prominent voices in software advise companies to stop looking for rockstar coders.)  Of course, these opinions don’t impact how <insert your favorite company here> labels its engineering opportunities.  There are no standard definitions.

Compounding the confusion is the fact that building software is (or can be) so much more than just putting pen to paper, so to speak.  The product development process is sliceable in many ways, and each of those slicings has its own unique set of responsibilities, and, of course, job titles.  

So whether you’re a Computer Science student who’s trying to decipher what the heck is going on, or just an onlooker who wants to understand the tech talent world a bit better, let’s break it down.

Overview: The Product Development Process

The development process encompasses these steps:

  • Ideation – understand the product and come up with ways to improve it.
  • Specification – gather and document requirements.
  • Design – deliver mockups of proposed changes or elements thereof.
  • Architecture – plan out how code will be used to build stuff.
  • Implementation – convert documented plans into executable code.
  • Testing – provide quality assurance for engineered solutions.
  • Delivery – facilitate releasing software solutions to the business or clients.
  • Support & Maintain – help resolve production issues.

product development process breakdown

In upcoming posts, I’ll dig into each step of this process – what it means, which roles are involved and who does what. Hopefully, this can help you to focus your job search in the right place!

(A caveat for those truculent techno-feelie technophiles reading this: for each example that follows, we know there are a variety of counter-examples, substitutions, and exceptions that can be made – this is just a general overview of a sampling of roles with brief notions as to what they involve.)

Ideate

The leader of this process is generally the much-coveted Product Manager. The Product Manager (PM) is the chief evangelist for a product.  In the poetic words of Dave Stanke, a PM at Google, product management is the “facilitation of forward movement, through inspiration and influence.”  

where the product managers responsibilities lie

This is a job that wears many hats.  A PM advocates for stakeholders, helps turn ideas into a roadmap, ensures deliverables are of high quality, and supports everyone and everything by staying happy and optimistic all throughout.  Some PMs might do a bit more design work, with detailed interactive mockups; some PMs might actually build tests by writing executable stories such as via a framework like Cucumber; and some PMs are quite technical, and would jump into the code… if only the rest of the team would let them.

Some other titles associated with Ideation and Specification: Business Analyst, Systems Analyst, Change Manager, Program/Project Manager, Sales Engineer.

Design

In a small enough shop, the PM also serves as a User Experience (UX) Designer, someone who focuses on improving the quality of interactions between users and the product.  In larger firms, a PM does more strategizing across stakeholders while the UX Designer is  more of a Cognitive Science role, driving how the product is used, incorporating elements of marketing and graphic design.  In the smallest of shops, everyone’s a PM!

UX Design is not the same thing as either User Interface (UI) Design or Graphic Design, both of which are more art-focused with proficiencies in things like Adobe Creative Suite and styling web pages (which may be in code).  Ken Norton, a Partner at Google Ventures and an Ex-PM at Google, notes that, “UX is focused on the user’s journey to solve a problem, UI is focused on how a product’s surfaces look and function.”  

Some other titles associated with Design: Business Analyst, Web Designer, Accessibility Specialist, Interaction Designer

Architect

An Architect (add whichever prefix you prefer: Software, Technical, Information, Data) is someone who can map out how business specifications translate into a software solution, before any code is written.  

This is analogous to physical-space architects who create blueprints for buildings, bridges, and tunnels, planning out all of the details, big and small.  As experience from past projects helps inform architectural decisions, the software architect is usually a more senior role.  The Architect must have a vision for how the various components interact, how the product scales as its use and complexity grows, as well as consider things like security, performance, and data management.  The architect might help implement things, or might not.  Some more details over at Quora here.

Some other titles associated with Architecture: Solutions Engineer, Data Scientist, Database Administrator.

Implement

When it comes to the actual coding, as previously noted, there’s every flavor of job title.  Consider:

  • Pick one or more: Frontend, Backend, Full-Stack, Web, Systems, UI, Application, Mobile, Game
  • (Also, typically for finance: Front-Office, Middle-Office, Back-Office)
  • Pick another: Developer, Engineer, Programmer, Coder, Hacker, Rockstar, Ninja, Guru, Analyst
  • Optional prefix: Junior, Senior, Lead
  • Optional suffix: Level 1, Level 2, …, Level X

For example: Junior Backend Developer, or Senior Full-Stack Web Engineer Level 2.  

In addition, a developer might specialize in a particular language, framework, operating system, or piece of technology.  You might be a Junior Python Backend Developer, or a Junior Python/Django Backend Developer.  You could also be a Database Developer or a Unix Rockstar.

One frequent point of confusion is around the distinction of “frontend” from “backend.”  Ordinarily, frontend refers to the parts of an application that users see and interact with, whereas backend refers to business logic and data storage.  For a website, for example, the frontend (the web page you see) will be written in a mix of HTML, CSS, and JavaScript while the software serving that web page could be a mix of Python and SQL.  As languages evolve and web browsers become more sophisticated, the distinction between the two ends blur.  A few years back, if you knew JavaScript, you were a frontend developer; now, with Node.js, that same developer can do both frontend and backend work.

Test

Many large companies have dedicated testing teams of people that go by varying names such as Quality Assurance (QA) Engineer, Automation Engineer, or even just Test Engineer.  Testing is obviously an important aspect of building software – we want to ensure what we built not only works (QA), but that it works to our business specifications (User Acceptance Testing or UAT), and furthermore, that what we built hasn’t broken something previously built (Regression Testing).

 

In (sorry to say) the most inglorious of these jobs are people that do manual testing, which entails following a test plan, clicking through step by step, making sure the results are consistently correct.  At the other end are people who write automated tests in code – in many cases the testing code can be more complex than the application code itself.

Support

Network Operations Center (NOC) Engineers are folks who help monitor systems to ensure availability and reliability.  When things go wrong in any way, the NOC is usually the first to know or hear about it.  

 

In some cases, the NOC may act as a first level of support and try to resolve the problem, and in others, the NOC will need to escalate out to engineers more familiar with the broken application or system.  Sometimes, NOC Engineers will have no coding experience, and in others, they’ll have significant amounts and are expected to build internal tools that help with monitoring and supporting system stability.

Some other titles associated with Support: Support Technician, Technical Solutions Engineer, System Administrator (SysAdmin), Database Administrator, Helpdesk Support, Operations Analyst

Engineer++

There are a few other big categories of engineers worth noting, but that don’t fit as well in the product development process:

  • “Systems” Engineers: people solely focused on supporting the infrastructure and environment of the firm.  In these cases, the “product” is the environment (your corporate desktop, for example).  The System in these cases can span any of these technologies: Database, Windows, Linux/Unix, Network, Email, Messaging, VOIP/Telephony, Storage, Data Center, and Security/Privacy.
  • Engineers who Support the Engineers: DevOps, System Integrator, Technical Expert, Developer Relations, Cloud Architect, and Tools Engineer.
  • Social Media Specializations: in some cases, certain digital marketing roles fall under the purview of technology.  These span roles such as Marketing/SEO Technologist, Digital Media Marketer, and Growth Hacker.

Senior and Seniorer

With any of these roles, remember that as your experience or level of managerial responsibility increases, so does the title!  Two possible pathways, for example:

Don’t be the Titanic

Job title is the just the tip of an iceberg that makes up a technology opportunity.  We can make some generalities on primary, functional responsibility from a title, but hopefully this post clarifies that code-writing is but one sliver of what goes into delivering software solutions.

We here at Scouted are excited to see more and more software opportunities lining up on the platform, and look forward to helping all our technical candidates in landing those roles!  As always, reach out if you have any questions!

Leave a Reply

Your email address will not be published. Required fields are marked *