Developer Vs. Programmer

At ApexSQL we're making killer tools for SQL Server, and to do so we're proud to have strong product and website teams currently consisting of developers and SQAs. We have no programmers in our teams and we don't need any.

What is the difference between a programmer and a developer?


Definition

Programmer is a grunt receiving orders from a team leader and/or project manager working on a piece of code outsourced for someone else's solution and based on someone else's plan.

Developer is a spec-ops, lean-mean-development-machine part of a small band of heroes owning and building top-notch solutions, come hell or high water.


Examples

Programmer has many bosses: a senior, a team leader, a project manager, etc.
Developer has only one boss: the customer.

Programmer wants to write a program or some code.
Developer wants to create the best solution for the customer.

Programmer comes to work and works for 8h.
Developer has incremental results each day regardless of hours worked.

Programmer asks questions.
Developer makes suggestions.

Programmer speaks for himself as one from the team.
Developer speaks to the team and for the team.

Programmer reads roadmaps and writes code to accommodate roadmaps.
Developer makes roadmaps and works to accommodate customers.

Programmer doesn't know the competitors and tends to be surprised.
Developer knows what competitors had for breakfast and what they plan for dinner.

Programmer schedules meetings and gives updates to stakeholders when asked to do so.
Developer has an active com-link with battle buddies and keeps stakeholders constantly informed of mission status.

Programmer learns when new skills are needed for work and/or is trained by others.
Developer learns organically and shares the knowledge by training others.

Programmer works with other teams to share personal workload.
Developer works with other teams to lessen everyone's workload.

Programmer strives not to fail the sprint.
Developer strives to add more work on top of a successful sprint.

Programmer waits for SQAs to test code changes and report bugs.
Developer self-tests new code and makes it tough for SQAs to find bugs.

Programmer is unsure about performance of created tools.
Developer perf-tests regularly and knows that owned tools are top-performers in the market.

Programmer expects of SQAs to write test cases and to regression test everything.
Developer cooperates with SQAs to write unit tests, to implement detailed logging and to automate regression testing.

Programmer uses 3rd party tools to speed up work.
Developer uses our company tools to speed up work and to help improve the tools in the process.

Programmer "overcommits", "cannot reproduce", "cannot fix", "must ask someone else".
Developer gets the job done. Period.

Hard sh** and smart sh**

Great GSD ("Get Sh.. Done" as ApexSQL Nis office central poster says) = consistently have both short term and long term transparent results

Some teams are working using Scrum work organization through goals (answer to what?) and tasks (answer to how?), while others have monthly goals / quotas to achieve by making daily and weekly progress in smaller increments

We often forget about the goals while focusing exclusively on the tasks at hand to get them finished no matter what, forgetting about what is actually needed in the end and in what time

Now I'm not saying that focusing on daily tasks is wrong - one of my own email quotes from the early days said:

"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it." - John Carmack

 

We must always keep in mind both the goal and have Daily deliverables at all times

But in order to grow, besides working hard we must also be cognizant of the end goal at all times and be able to work smart to achieve the goal

GSD has two levels:
   1) Hard Sh**: daily deliverables, things we must all do our part and complete in order to make daily progress, i.e. fix stubborn bugs, test bug fixes and report new bugs, write TS articles for unfixed bugs, publish articles, communicate with stakeholders, share your progress daily, etc.
   2) Smart Sh**: make a dent in the universe by aligning all action with end goals and complete the goals with a reasonable amount of effort in a reasonable amount of time

How does Smart Sh** translate to your everyday work?

   a) Dev teams should realize that customers don't have a use for 50 bug fixes in code and would much rather prefer 20 bug fixes in a product build they can actually download - know when to cut and deliver.
   b) SQA should invest time to understand product usefulness, to learn about it and to use it as customers use it in order to test the product well, to never assume they know everything, to write about it in non-hamburger helper way, and to excel in customer support.
   c) Everyone should be investing time into ERF mentorship with new colleagues so that they can start contributing back and in turn save time to you.
   d) Everyone should automate repetitive work - currently a huge soft spot in multiple teams.

What does automation have to do with working smart?

A lot: one of the funnier historical examples is several devs going rogue and writing a software that fully automates sending Daily Scrum Summaries - while other teams were taking hours of time weekly to manually compile good Scrum Summary emails, these devs took one day and created a two-click solution that in turn saved them days of time; I always received spotless Scrum Summaries from their teams which was a mystery to me until I found out about the "plot" ;) (devs are good guys, they were planning to distribute the software to everyone when we stopped sending these emails daily)

 

Time is a limited commodity so by investing some in order to automate repetitive work (smart vs. hard), devs gained more time to focus on what really matters: to write better code and to deliver great products to the customers in order to make a dent in the universe. I'm also sure devs had more fun in the process ;)

Ultimately whatever we do we must ask ourselves:

   A) Can I complete the task at hand more efficiently with less effort and time?

   B) What goal will be closer to completion when I finish this task today?

   C) What will I deliver to customers when the goal is completed?

   D) Will the customers pay me for the deliverable?

 

If no one will pay you in the end, why would you do it in the first place? ;)

ERF - Expectations, Results, Feedback

The first badge for leading and sharing is awarded for successfully leading your team to achieve defined goals, and for maintaining transparency of team progress while sharing new experience and knowledge with peers and seniors

However the second badge for leading and sharing is more challenging and requires sharing to new colleagues how they can share-and-lead

Here is a proven good way to earn the second badge through ERF (set Expectations, review Results, provide Feedback):



When in doubt, just follow the three ERF steps:
  1) Set Expectations - clearly explain what is the final goal of the deliverable, why do we need it, what is the epic story behind it; provide a system description or example of similar work from before; go back to your own goals and don't interfere
  2) Review Results - once the results are in, dedicate time to review them in details, what is good, what is not so good, and make notes for everything; don't fix the results yourself
  3) Provide Feedback - take all your notes from the previous step, dedicate more time to make them as clear as possible before sending; finally send all the feedback and repeat expectations - go back to step #1 and repeat the full cycle until finally results match expectations


Also there are multiple ways through which you will never achieve the second badge, i.e.:

Don'ts to watch out for:
  1) Don't expect results without first setting expectations and clarifying them
  2) Don't yell when results are not matching expectations - instead just provide actionable feedback and repeat expectations
  3) Don't set deadlines based on how much time you would need to complete the same goal; however make sure to always have clear ETAs and to follow up on time as needed
  4) Don't fix low quality results yourself - instead ask for resubmission after providing feedback
  5) Don't confront when you identify a problem - instead ask for clarifications and observe
  6) Don't IM or voice-only your feedback - instead share it so that it can be traced back easily on G+, emails using #hash[tag]


How will you know if you have succeeded in mentoring new colleagues? They'll be the ones to achieve defined team goals and to share new experience and knowledge with you