$ git stash poop
fatal: unknown subcommand: poop
usage: git stash list [<options>]
or: git stash show [<options>] [<stash>]
or: git stash drop [-q|--quiet] [<stash>]
or: git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: git stash branch <branchname> [<stash>]
or: git stash clear
or: git stash [push [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]
[--pathspec-from-file=<file> [--pathspec-file-nul]]
[--] [<pathspec>...]]
or: git stash save [-p|--patch] [-S|--staged] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [<message>]
$ Why do you have to be so literal?
bash: Why: command not found
Imagine being at lunch with a bunch of fellow developers, and you all are ranting about all the things that are going wrong at the company. You guys could be talking about your below-market salaries, the tech debt piling up in the same manner as the U.S. national debt, the frequent scope creep, the rotting company culture, and so on. You and your friends might be thinking, Why haven’t I switched jobs yet?
I’m sure all of us software engineers have had conversations like these from time to time. Let’s face it—no company is perfect, and work can be frustrating at times. Here I will list some of the biggest pain points I have faced throughout various points in my career, in no particular order.
“There is no QA.”
Why on earth would you ever need a test environment when you can simply deploy things straight to production and then mark the stories as done?
Few things are more stressful than not having any dedicated QA personnel to ensure that the product meets high standards before it is shipped out to customers. In this high-pressure situation, a single mistake is very costly. Customers become very angry when they find out that a key feature is not working for them and their business is hosed because of it. They are the ones performing the QA but are not getting compensated for it. Word spreads around that the product is buggy and outages are common. The product’s reputation suffers, and customers flee to competitors.
Without support from QA, I had conditioned myself to get the job done right the first time most of the time. But as much as I’d like to do a perfect job at what I do, I’m not superhuman. I still make mistakes. Time is short, and I must consistently meet deadlines. With much of the code not being unit-testable, I often did not have the time to refactor it to make it unit-testable. When I was fortunate enough to get the unit tests written, the fact remained that I lacked the perspective that a dedicated QA person would have.
In one particular failure, I fixed a bug by wrapping a variable inside some business logic. However, that broke something else out in left field, nearly leading to a catastrophe. I was rewarded with a poop emoji pillow for my efforts.
“The company culture is not what it used to be.”
I just quoted what I overheard someone say at a meeting during my first month at a new job. I didn’t think about it much at the time because, being the new guy, I had no reference to compare the current company culture to times past. But over time, things got worse.
The engineers I worked with at this company were some of the best I have ever worked with, and I had great relationships with them. Management, on the other hand, was a different story. Don’t just take my word for it; feel free to consult the vast number of Glassdoor reviews of outstanding employees sharing different angles of the same story. Although there were some really good managers, there were other managers I did not trust.
Now, I’m not here to throw anyone under the bus, name names, nor give out too many details. I will say that I was once asked by management to approach things in a way that contradicted my core values. I have also been lied to on occasion.
The company had a cultural problem. Everyone knew it. All too often, great employees would jump ship and find greener pastures. Others were let go because they were top performers.
“I have an idea! We should use a database!”
On second thought, let’s not use a database. Databases are stupid. We should just store everything in RAM.
After all, RAM is really fast, and so are HashMaps. Plus, the company doesn’t need to hire any DBAs to monitor slow queries if there aren’t any database queries to monitor.
Besides, the company had more pressing things to prioritize than integrating a relational database into the monolith. Adding a database would have been too much of a hassle.
class EmployeeDB {
Map<Integer, Employee> employeeCache = new HashMap<>();
public EmployeeDB() {
loadEmployeesIntoRAMAndAvoidUsingADatabaseAtAllCosts();
}
public Optional<Employee> getById(int id) {
return Optional.ofNullable(employeeCache.get(id));
}
private void loadEmployeesIntoRAMAndAvoidUsingADatabaseAtAllCosts()
{
Map<Integer, Employee> newEmployeeCache = new HashMap<>();
// What's better than loading everything into RAM?
// Shoving them all into an intermediate list before we map IDs
// to them, even if there are hundreds of thousands of employees.
List<Employee> employees = loadAllEmployeesFromDiskOrSomeAlternativeThatIsNotADatabase();
for (Employee employee : employees) {
newEmployeeCache.put(employee.getId(), employee);
}
// Garbage collectors love it when you swap out a huge object
// for another one.
employeeCache = newEmployeeCache;
}
}But never mind the frequent long-lasting stop-the-world GCs, CPU spikes, HTTP 503’s, the aging technology being pushed to its limits, and so on.
All the time spent investigating stop-the-world GCs and CPU spikes could have instead been invested in paying off tech debt and switching to more modern technologies, such as—you guessed it—a database!
“My productivity has been reduced by 75%.”
I was used to being in a smaller room where my team was isolated from the rest of the company. The room was quiet except for communication among team members. I was super productive.
Then the time came for all of us to move over to a different building across the complex. What could possibly go wrong?
My teammates and I found ourselves in a wide open environment full of voices echoing from all directions, largely coming from the much more talkative sales and support reps. There were no cubicles nor walls to absorb the noise. Whatever hope we had for peace, quiet, or concentration were quickly dashed despite the noise-cancelling headphones. In fact, one of my teammates was so upset that he threatened to quit on the spot.
“We do all we can to invest in our employees.”
It is common in company meetings for the CEO or some other executive to tell us about how much the company invests in its employees. Generally, I only believe them if the company is actually investing in its employees.
The following are some obvious signs I have seen that the company is not investing in its employees:
- Team members often complain about below-market salaries.
- Opportunities within the company to learn new skills according to market demands are very rare.
- Top individual contributors do not receive well-deserved promotions because the company does not have a career path for them.
- The team gradually shrinks over time as top performers frequently leave for better opportunities, and the company does not fill the vacant positions.
I once worked at a company where a large portion of the developers had to work 12-hour days. Talk about a horrible work-life balance. Luckily, I wasn’t one of them.
By the way, about that same guy who was so upset at the noise that he threatened to quit on the spot—he eventually did quit soon after that to join another company that paid him twice as much!
“Why did all my code just get reformatted?”
I once did some extensive development on a WordPress plugin. I spent countless hours cleaning up its cruft and refactoring it so that development of the plugin would be so much easier moving forward. I even updated its formatting to use PSR standards, which yield a much cleaner coding style.
Comparing the PSR standards to the WordPress coding standards is like comparing apples to rotten apples. Anyone who has programmed in PHP knows that the PSR standards are so much better. For those of you who disagree with me, I dare you to prove me wrong in the comments. The WordPress standards make we wonder what might happen when a C developer is hired to write PHP code.
<?php
// PSR-12
class FooBar
{
public function doSomething($someVar1, $someVar2, $someVar3)
{
if ($someVar1 && (!$someVar2 || $someVar3)) {
// ...
} else {
// ...
}
}
}
// WordPress
class Foo_Bar {
public function do_something( $some_var1, $some_var2, $some_var3 ) {
if ( $some_var1 && ( ! $some_var2 || $some_var3 ) ) {
// ...
} else {
// ...
}
}
}However, someone else from a completely different team (who also had access to the repository) decided that the plugin needed to follow the WordPress coding standards. Without consulting me first, he reformatted my code accordingly. The resulting code looked like someone vomited a bunch of space characters. Knowing that the PSR coding style was permitted in WordPress plugins (unlike WordPress core), I reverted his formatting change (without first consulting him about it).
“My brain is fried.”
Once upon a time I had the honor of discovering a pretty serious bug. Essentially, an important feature that clients used to create queries based on custom objects was completely broken. I found that the bug was caused by an error in refactoring where the custom objects were not taken into account.
The newly refactored code was quite difficult to understand. Naturally, the next step would have been to reach out to the developer who performed the refactoring for help in fixing the bug. But there was one small problem: the developer in question had (for unrelated reasons) already been fired!
What followed was myself and a teammate spending two consecutive brutal 16-hour days wrapping our fried brains around this labyrinth of a refactoring before we finally came up with a hacky solution to get the custom object queries working again. During this time I attempted several times to take naps on the floor, but with very limited success. By the time this was all over, I had become a zombie—just not the flesh-eating kind.
After I pulled the all-nighter, I remember my manager denying my PTO request in which I was supposed to take that next day off, and then telling me to go home and get some rest. (That way, I could still take the remaining day off without using up any PTO balance.)
“If you don’t use a Mac, everything will break.”
Macs are for artists, not developers.
The most difficult thing about using a Mac is using a Mac. One thing that is particularly frustrating is having to get used to a different set of keyboard shortcuts to accomplish what I could do in Windows with ease. Also, I can’t just simply snap windows left and right without doing some extra configuration.
Before I was hired at one of my jobs, I had the option to choose between a MacBook Pro or a Lenovo. It was recommended that I get the MacBook Pro because everyone else on the team had one. Moreover, not having a Mac would mean that the programs I would try to run would break. At least that’s what they said. To remain on the same page as the rest of the team, I chose the MacBook Pro.
I instantly regretted my decision the moment I struggled to open the MacBook Pro laptop for the first time. That darned laptop was quite harder to open than it needed to be, and I had to use both of my hands; whenever I tried using just one hand the laptop would just slide further away from me toward the wall. Once I finally opened it, the first thing I noticed were some strange symbols where the Ctrl, Alt, and Window keys would have been. As my eyes glazed over the rest of the keyboard, I discovered that the Print Screen key had gone AWOL.
Apparently, pressing Command + Shift + 3 to capture the entire screen is more intuitive than simply pressing the Print Screen key. (Anyone would guess that, right?) Try learning that keyboard shortcut without first consulting Google.
Learning how to use a Mac was a big struggle for me. Looking back, I wish I had chosen the Lenovo. I’ve found that projects that “only work on Mac” work for Linux also. I would have experimented with using Linux, or at least using Windows Subsystem for Linux, for those projects. I also would have invested some time into fixing those projects to work for Windows.
What kinds of frustrating experiences have you guys had as software developers? Let me know in the comments!