Two observations on software engineering
Posted in :
For a guy with a hammer, everything is a nail
Use SQL for everything
At Mastercard, I used to have a colleague who is great at SQL. And once I realized he used PL/SQL for quite complex business logic for a “promotion build” and it backfired. The customer noticed there were some inconsistencies and notified us. Upon further examination from yours truly, it appears the code has some logic flaw. Note the flaws in the PL/SQL is hard to detect, compared to code/app written in a more general purpose programming language such as Java and following proper testing procedure. The cost of that mistake is we end up sent about $40 k to the business customer (a bank). I can understand why PL/SQL is being used there, because that’s the main skill my former colleague had, and in other words, he has this hammer (SQL), and he was using it at every place possible. A second reason is my manager was probably under pressure to deliver that functionality, and he probably was not willing to or getting help from the dev team: and I knew we have quite a few Java developers there, and some of them are pretty good.
Performance Testing went too far
This applies to performance testing (JMeter is a popular tool). When I worked at Ascension, my boss likes running performance testing via JMeter. Also at the time, we have an engineer who knows the tool. And once we ran performance testing without realizing that we sent emails in our testing, and our testing brought the company outlook server down to its knees 🙁 In hindsight, I felt this kind of testing is not really necessary. You can read some of the examples I listed in my blog post too. The lesson here again is: someone fell in love with the performance testing, or performance of the system. I am not saying it’s a bad thing, but the approach they were taking to me is very amateurish. And as you can read from my blog post, that’s one main factor a multi millions dollars project failed. Somehow the recent DOGE efforts in finding fraud and waste in the US government reminded me of that failed project.
Layoff to cut cost
Now Elon’s DOGE team seems got obsessed with cutting staff (hammer) in the federal government: which was first used during the Elon’s Twitter takeover. He is using that hammer again from his previous experience. In short term, if you cut staff, you may get some more productivity from the remaining staff, because the remaining people will be scared and have to work harder to make up the slack etc. But there will be longer term consequence. I don’t think it’s as straightforward as cutting staff at Twitter (X). But again Elon only knows hammer. He really doesn’t have other tools in his toolbox.
I am pretty sure this “hammer/nail” mentality applies to other fields as well. For example I saw quite a few Asian parents pushing kids to work harder (the main reason is those Asian parents mostly worked hard to get here), without realizing “work smarter” is actually way more important.
How to measure the productivity of software engineers
My short answer is you cannot. But for managers they cannot take this answer, especially at the places they have mandatory quota based layoffs, in America I recall Jack Welch is the one who started it: refer to Jack Welch: how he justified his famous ‘fire the bottom 10%” and Short-term profits and long-term consequences — did Jack Welch break capitalism?
And at Mastercard, in early 2019, yours truly was hit by that too. I was Lead Software Engineer at the team, but unfortunately I got into some “grunt” work, not necessarily code related, thus my GitHub stats was not great.
What are the grunt work? You may ask. And since you ask me: I would ask google. Here are the answers from Google’s Search Labs | AI Overview
======
“Grunt work” in software development refers to the repetitive, often tedious, and basic tasks that are necessary to complete a project, like data entry, basic code cleaning, configuration management, or setting up initial infrastructure, essentially the foundational work that needs to be done before moving on to more complex features or design elements. Key points about “grunt work”:
- Not glamorous:It’s not the most exciting part of development, but it’s essential for a smooth project workflow.
- Early stages of development:Often done at the beginning of a project, especially by junior developers, to learn the system and establish good practices.
- Can be automated:Many tools and scripts are used to automate repetitive grunt work, improving efficiency.
Example of grunt work in software development:
- Setting up test environments
- Data migration from an old system
- Cleaning up legacy code
- Writing basic unit tests
- Creating boilerplate code
- Managing project dependencies
======
So my lesson learned from there, along with a similar lesson I learned from Ascension Health, is: coding more, and do less of the grunt work.
At least, when a manager who only cares about those stats come by (aka, someone like Elon Musk), I can point to the source code repository, and show her/him the stats.
In reality though, layoff is more than just the stats.