Hiring Programmers is a Risky Venture

Architect/Programmers like Nate Allen in Mapleton, Utah are rare. They create a well-thought-out design that scales and then program the foundation very well for the first release.

Once code works you want programmers to fix bugs, enhance it safely and port it to new operating systems, languages and platforms when needed.

Hiring programmers is a risky venture. None of the full-time programmers I employed ever provided a return on investment. They came to work mainly to get a paycheck. When resources were low or their skills had improved they were lured away by other companies.

One contract programmer though did complete most of his tasks and we released and sold the products he ported to the Mac.

Programming sweatshops are the worst–their programmers are only dedicated to your project when you allocate bags of money and then abandon it to work on other projects. They often over-architect software and implement unnecessary design patterns that aren’t needed and make the software more difficult to work on. They have no passion or interest in your solution so unless you provide very detailed and prioritized specs, they will probably drain your monies.

If I could do life all over again I would have done all my programming myself or teamed up with a co-founder/programmer with passion and the resolve to weather difficult financial times.

Programmer David Pugmire once told me there were very good former Microsoft programmers who worked in the Seattle area that he felt made great contractors. He hired them as a manager at Microsoft so I am sure he provided them with very detailed specs, testing resources, held them to Microsoft’s rigorous standards and provided the finances for them to complete the job.

Programmers are better employees when passionately committed to your vision.

Although most programmers prefer to work alone, most work better in pairs because pair programming results in better designs, faster implementation, fewer bugs and better code.

by Robert John Stevens, January 23, 2018

Save Money Before Hiring Programmers

by Robert John Stevens, September 19, 2016

Programmers can quickly become very expensive: Given their cost and time estimates, a good rule of thumb to determine the final cost is to multiple by pi.

Validate your idea before hiring programmers. BYU’s Business Management 472 will teach you how. The course’s book “Startup Marketing Essentials” by Gary Rhoads, Michael Swenson and David Whitlark can be located at myeducator.com. Older editions were called “BoomStart: Super Laws of Successful Entrepreneurs.”

BYU Dr. Nathan Furr’s, “Nail it Then Scale it” is another must-read book that will teach you how to work with your customers to design a product they’ll buy and use.

Create wireframe mockups of your screens. There are many tools for this including Balsamiq (https://balsamiq.com/) which you can learn in minutes. Spend a month with your customers testing and perfecting your black and white designs so they’ll focus on your solution rather than its artistic appeal.

Then add full color to your screens and re-test. If you are artistic use a tool like Photoshop, Illustrator, Adobe Muse or PowerPoint. If you are technical use HTML5 and CSS 3, and a framework to make it look good like Bootstrap, Google Polymer or Angular Material.

The more you can do to prove your idea and work out the details with your customers, the less you’ll pay programmers.

Programmers prefer detailed specifications. Uncertainty and change requests will just cost you more money.

Dr. Dallan Quass’s roadmap for an interactive design is:

1. PowerPoint prototype with clicks going to different slides,
2. Angular, HTML + JavaScript
3. Rest server
4. Hook up prototype in #2 to a server in #3

C++ Erodes; Python Climbs

Letter emailed today to BYU CS Professors:

July 31, 2016

Dear BYU Computer Science Department,

You’re insistence to continue teaching C++ is having enormous unexpected negative financial consequences for employers.

C++ continues to erode in popularity while Python continues to climb. Kevin Seppi has been right all along:


When we hire BYU CS programmers it costs us in both time and money to retrain them in TypeScript, Python, Java, Ruby or C#. Often other programmers rewrite their C++ code in another language.

The problems I outlined are rampant even in my family: Three of my children were taught C++ from your CS department. The popularity of JSON.NET is enough reason to switch to C#.

I’m told the initial reason for the BYU CS Department to switch from Java to C++ was because the BYU engineering department requested it. To that may I ask–How often has embracing the needs of niche or minority power users led the downfall of software projects?

Armed with Python as one’s primary programming language, programmers feel empowered to quickly create scripts to solve problems.

Programmers are human and humans tend the embrace easier technologies: Python and TypeScript are both easy and powerful.

Python is quickly becoming the choice for scientific programming:

MVC frameworks are being replaced by client-side frameworks such as AngularJS. TypeScript is the language choice for AngularJS 2.

Dallan Quass recently emailed me and said he regrets not embracing TypeScript sooner because its strong type checking would have caught most the errors he’s now finding in his client-side Javascript code.

From the programming language survey data I hope you can see that the world continues to abandon C++.

Over the years I have been told repeatedly that switching to another language for CS 142 is not trivial. I don’t believe that because I know I could teach it using Python or TypeScript, but if the claim is true then the argument should be considered it is even more nontrivial for programmers to switch once they have been compromised having learned C++ as their first language.

Rather than continue to propagate a mistake, please teach Python and TypeScript this fall. The positive repercussions will be enormous and long lasting:

We employers won’t have to pay to retrain, projects will cost less, ideas can get to market quicker, and we’ll have more money for philanthropical contributions.

Best Regards,

Robert Stevens

How many programming languages do you know?

by Robert John Stevens, June 15, 2016

I interviewed by phone this morning with a programming manager at G3 Technologies in Ashburn, Virginia after seeing his ad mentioning Elasticsearch. He said they program with ASP.NET (dying ASP.NET), not ASP.NET MVC, and he never mentioned Elasticsearch although I boasted how wonderful it is for high-speed read operations.

He also said if he were king of software he’d ban all future programming languages, that we don’t need anymore and to prove it he tells his employees to read out loud the list at the Timeline of programming languages and name how many they know.

The programming languages I learned

Here is the list of programming languages I learned from 1981 to 2016:

  1. Motorola 6502 Assembly Language
  2. Data General Assembly Language
  3. Intel Assembly Language
  4. VAX Assembly Language
  5. LISP
  6. Fortran
  7. ALGOL
  8. COBOL
  9. BASIC
  10. Forth
  11. Pascal
  12. C
  13. SQL
  14. Bourne Shell (sh)
  15. Modula-2
  16. Ada
  17. Turbo Pascal
  18. Objective-C
  19. C++
  20. Perl
  21. Bash
  22. Python
  23. Visual Basic
  24. Borland Delphi
  25. ColdFusion
  26. Java
  27. PHP
  28. Ruby
  29. JavaScript
  30. Curl
  31. ECMAScript
  32. C#
  33. Visual Basic .NET
  34. TypeScript

This list doesn’t mention HTML or CSS.

The manager asked for me to propose a lower salary than $65 an hour because I programmed in ASP.NET MVC recently and not ASP.NET.

I know D.C. programming shops are expensive. A friend who works at the NSA once told me he couldn’t hire contract programmers for less than $250 an hour.

Then the manager said the job may last 17 days or 17 months and I should send him samples of my code for his review, and they have so much business that they turn down work.

It is best to work for companies who wish to expand your views, their profits and to financially motivate you for your contributions and excellence.

Always accept the job where your skills will be best improved. If you do you should always have work.

Consider never accepting a job that programs in dying technologies unless you’re prepared for it to be your last.

Are Older Programmers Relevant?

by Robert John Stevens, June 13, 2016

A potential employer sent me an email today which includes these classic but insightful statements that are akin to firing a cannon bow over the bow of an old ship:

Andrew [their software development manager] firmly believes that years of experience and years of learning are not necessarily correlated, so in many cases, if the software engineer has not spent a lot of time in continuous learning, they are not valuable just because they are older engineers and have been in the industry for years. Many companies have opted to get rid of the older engineers and hire two younger ones for the same salary. We are seeing this happen all of the time, mostly at the larger companies.

As we get older we think and accumulate insights about our profession. Although I’m a programmer, I suspect these thoughts are relevant for many other technical professions:

Looking back on your career, did you become smarter and more valuable? How will that change in another five or ten years? Will you be more or less relevant? How will you compete with younger professionals?

Have you realized that 75% of startups and 90% of projects fail? These statistics apply to the companies you worked for, the projects you worked on and your friends’ resumes.

What makes a good programmer? Is success a result of hard work, passion, dedication, knowledge, teamwork, teachability, wisdom, drive, insights and persuasion? How could you have identified past failures and predicted winners?

Over time do you think more about correct principles than details such as programming language syntax?

Can you identify programming teams that spent millions if not hundreds of millions of dollars on projects that were challenged by one to six programmers who created a competitor offering in a fraction of the time and on a very small budget?

Have you noticed that new college graduates, although smart and fast, never learned in school how to perfect and release a product as we did at work?

Is programming really a career or a short-term opportunity for the young as is professional football ?

Is a programmer’s career a bell curve that peaks out at a certain age and becomes less valuable over time?

I haven’t quit to become a Realtor or a car salesman because I enjoy programming, have a genuine love and passionate for software development, am fascinating by emerging web technologies, am motivated to provide for my wife and young children, and am still passionate about doing something great with my life.

The best programmer I know is Dallan Quass, the former CTO of FamilySearch.org — a billion dollar software project. He’s in his early fifties and is rewriting FamilySearch all by himself using modern technologies. I’ve seen it. He can do it. He will do it. My goal is to be more like Dallan.

I know living near work is a huge benefit, especially for older programmers. Working outside my own startups I may learn a lot and feel great satisfaction working with other smart people. I’m sure I’d mentor others, freely share wisdom and help steer them better. I am also sure I’d fix critical problems where others gave up.

Corporate teams know what competitive salaries are and what motivates good people to join and become top contributors, but how do those rules apply to older programmers?

No interview will compensate for working alongside new programmers. We learn a lot after a day, more in a few months and the most in hindsight.

Are older programmers relevant? Maybe. Maybe not. StackOverflow reports only 2.4% of programmers are 51 and older. I think it really depends on how motivated we are, whether or not we’ve kept current, and our ability to focus.

Personally, I’d just like to find one other good programmer to work with, or perhaps a small team of programmers who are dedicated to a cause, on a project we mutually believe in, somewhere where we can work without interruption, for a salary that will relieve us from financial pressures, and for enough time for us to succeed.


From Dr. Phil Windley

The problem, as you point out is that keeping up with changing tech is real work. Many people don’t want to do it. Software development isn’t like bricklaying or plumbing where skills don’t change quickly. Heck, there’s a new JS framework every day. You can ignore some of them, but you can’t ignore the trends. You can’t stop doing new things. I’ve been teaching CS462 for 17 years. And I’ve redone it a dozen times.

Younger programmers are often more enthusiastic about learning new things. And so they come across as more capable in a world that rewards cutting and pasting stuff from StackOverflow or wrangling a new framework.

I’ve hired older programmers in my career and I was attracted to them for their knowledge of the fundamentals of computer science, including parsing, AST optimization, operating system design, etc.

One advantage of younger programmers is that they’re sometimes freed by what they don’t know. Consequently they enthusiastically push forward undeterred by the problems down the road. Provided they don’t work themselves into a cul-de-sac, that’s probably OK.

From Al Gregory, Hyde Park Pros:

Thanks Robert! It’s funny, when I was a younger recruiter (in my late thirties) I would chuckle at candidates complaining about age discrimination. Now, in my low 50’s, especially in IT, I see it as a rampant problem. I believe that it is primarily a result of hiring managers being lazy. You kind of know what you get with two young programmer – but you have to dig pretty deep to find out if an older candidate is a Dynamo, a Cruiser, or a Loser (concepts from a book I read by David Maister).

It’s definitely a challenge to find a hiring manager who is willing to take on the challenge of really determining the potential value of an older candidate!

Why Programmers Don’t Like Recruiters

by Robert John Stevens, December 31, 2015

Do attractive people need to hire someone to find dates? Sometimes, but programming teams that are good enough to attract talent do not need recruiters, especially if they are led by well-respected leaders with magnetic personalities.

To assess whether or not programmers are tidy and presentable, recruiters often ask to meet them in person before presenting them to prospective employers. Do great programming teams care what a candidate looks like? Most will say no, especially when hiring top programmers.

When deciding between two candidates with comparable skills, corporations will usually avoid paying a recruiter’s commission and choose the freelance candidate.

Your chances of getting a job are much higher with in-house corporate recruiters.

Find jobs that are not yet posted. To do that, offer to take your employed friends to lunch. Do not delay—a few hundred dollars of lunches is a small amount compared to extended periods of income loss.

Remember, the longer you stay unemployed the more likely you will remain unemployed so avoid recruiters, get to work, remain positive, assume nothing, don’t say more than you need to during your interviews and get several employers to bid against each other for your employment.

And learn new tools and technologies to keep your mind fresh and sharp, to make the competition irrelevant and because programmers love to hire those using the latest and greatest.