If all you have is a hammer, everything looks like a nail!

This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.

Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.

While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.

Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.

I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.

Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!

Week 278: Most rage-inducing work experience — I’ve got a list saved! At least from the current circle of hell. I might post a few more under this tag later…

TicketA: Do this in locations a-e.
TicketB: Do this in locations e-h.
TicketC: Do this in locations i-k.
Root: There’s actually a-x, but okay. They’re all done.
Product: You didn’t address location e in ticket B! We can’t trust you to do your tickets right. Did you even test this?
Root: Did you check TicketA? It’s in TicketA.
Product guy: It was called out in TicketB! How did you miss it?!
Product guy: (Refuses to respond or speak to me, quite literally ever again.)
Product guy to everyone in private: Don’t trust Root. Don’t give her any tickets.
Product manager to boss: Root doesn’t complete her tickets! We can’t trust her. Don’t give her our tickets.
Product manager to TC: We can’t trust Root. Don’t give her our tickets.
TC: Nobody can trust you! Not even the execs! You need to rebuild your reputation.

Root: Asks coworker a simple question.
Root: Asks again.
Root: nudges them.
Root: Asks again.
Coworker: I’ll respond before tomorrow. (And doesn’t.)
Root: Asks again.
Root: Fine. I’ll figure it out in my own.
TC: Stop making it sound like you don’t have any support from the team!

Root: Asks four people about <feature> they all built.
Everyone: idk
Root: Okay, I’ll figure it out on my own.
TC: Stop making it sound like you don’t have any support from the team!

Root: Mentions multiple meetings to discuss ticket with <Person>.
TC: You called <Person> stupid and useless in front of the whole team! Go apologize!

Root: Tells TC something. Asks a simple question.
Root: Tells TC the same thing. Asks again.
TC: (No response for days.)
TC: Tells me the exact same thing publicly like it’s a revelation and I’m stupid for not knowing.
TC: You don’t communicate well!

Root: Asks who the end user of my ticket is.
Root: Asks Boss.
Root: Asks TC.
Root: Fine, I’ll build it for both.
Root: Asks again in PR.
TC: Derides; doesn’t answer.
Root: Asks again, clearly, with explanation.
TC: Copypastes the derision, still doesn’t answer.
Root: Asks boss.
Boss: Doesn’t answer.
Boss: You need to work on your communication skills.

Root: Mentions asking question about blocker to <Person> and not hearing back. Mentions following up later.
<Person>: Gets offended. Refuses to respond for weeks thereafter.

Root: Hey boss, there’s a ticket for a minor prod issue. Is that higher priority than my current ticket?
Root: Hey, should I switch tickets?
Root: Hey?
Root: … Okay, I’ll just keep on my current one.
Boss: You need to work on your priorities.

Everyone: (Endless circlejerking and drama and tattling)

The nightmare continues.

Currently dealing with a code review from a “principal” dev (one step above senior), who is unironically called a “legendary dev” by some coworkers. It’s painfully obvious he didn’t read the code, and just started complaining and nitpicking.

It’s full of requests to do things that make absolutely no sense, and would make the code an unmaintainable mess.
• Ex: moving the logic and data collection from the module’s many callers into the module instead of just passing in the data.
• Ex: hiding api endpoint declarations by placing them in the module itself, and using magic instance variables to pass data to it. Basically: using global functions and variables instead of explicit declarations and calls.
• Ex: moving the logic to determine which api endpoint to use, for all callers, into the view.

More comments about methods being “too complex” (barely holds water) right next to comments saying “why are these separate? merge them together!”

Incredulously asking how many times I’m checking permissions and how ridiculous it all is. (The answer? Twice.)

Conflating my “permissions” param and method names with a supposedly forthcoming permissions system overhaul, and saying I shouldn’t use permissions because my code will all have to get rewritten. Even if that were true, and it’s likely not, the ticket still needs to use the current permissions. I can’t just ignore them because they might be rewritten someday.

Requests to revert some code cleanup because the reviewer thought the previous heavily-nested and uncommented versions (with code duplication) were easier to read. Unsurprisingly, he wrote them.

On the same ticket, my boss wants me to remove all styling and clientside validation, debouncing, and error messages from a form. Says “success” and “connection failed” messages are good enough. The form in question sends SMS and email using arbitrary user input for addresses. He also says it shouldn’t be denounced on the server, and doesn’t want me to bother checking permissions. Hello, spam!

Related: the legendary dev reviewer says he can’t think of a reason why we would want to disable the feature for consumers, so I should remove the consumer feature flag.

You can’t make this stuff up.

➡️You Are Not A Software Developer⬅️

When I became a developer, I thought that my job is to write software. When my customer had a problem, I was ready to write software that solves that problem. I was taught to write software.

But what customers need is not software. They need a solution to their problem. Your job is to find the most cost-effective solution, what software often is not.

According to the universal law of software development, more code leads to more bugs:

e = mc²

Or

errors = (more code)²

The number of bugs grows with the amount of code. You have to prioritize, reproduce and fix bugs.

The more code you write, the more your team and the team after it has to maintain. Even if you split the system into micro services, the complexity remains.

Writing well-tested, clean code takes a lot of time. When you’re writing code, other important work is idle. The work that prevents your company from becoming rich.

A for-profit company wants to make money and reduce expenses. Then the company hires you to solve problems that prevent it from becoming rich. Confused by your job title, you take their money and turn it into expensive software.

But business has nothing to do about software. Even software business is not about software. Business is about making money.

Your job is to understand how the company is making money, help make more money and reduce expenses. Once you know that, you will become the most valuable asset in the company.

Stop viewing yourself as a software developer. You are a money maker.

Think about how to save and make money for your customers.

Find the most annoying problem and fix it:

▶️Is adding a new feature too costly? Solve the problem manually.
▶️Is testing slow? Become a tester.
▶️Is hiring not going well? Speak at a meetup and advertise your company.
▶️Is your team not productive enough? Bring them coffee.

Your job title doesn’t matter. Ego doesn’t matter either.

Titles and roles are distracting us from what matters to our customers – money.💸

You are a money maker. Thinking as a money maker can help choose the next skill for development. For example:

Serverless: pay only for resources you consume, spend less time on capacity planning = 💰

Machine Learning: get rid of manual decision-making = 💰

TDD: shorter feedback cycle, fewer bugs = 💰

Soft Skills: inspire teammates, so they are more productive and happy = 💰

If you don’t know what to learn next — answer a simple question:

What skills can help my company make more money and reduce expenses?

Very unlikely it’s another web framework written in JavaScript.

Article by Eduards Sizovs
Sizovs.net

INTERVIEWER: Let’s say client wants a gif in the EDM design but older outlooks don’t support it. How do you solve it?
ME: Maybe we can try using iframes if outlook supports them and host gif somewhere and use iframes to show it.
INTERVIEWER: Any other solution?
ME: We can probably also detect the email client and just show gif for all other email clients but a picture for outlook.
INTERVIEWER: No but the client wants the gif to show on all email clients
ME: But outlook doesn’t support gifs!!!
INTERVIEWER: yeah
ME: …..
INTERVIEWER: …..

I thought maybe I missed something having been a junior dev and never developing edms. So jumped on the internet after the interview and my second answer is literally how everyone does it. What even was the point of that question? At no point she said yeah that’s a good solution and that’s how we do it in the industry. If outlook doesn’t fucking support gifs then what the fuck kind of solution am I supposed to bring to the fucking table in 5 fucking minutes.

The HR for my last employer sucks.

After I left, my employer changed record keepers for the 401k before I could rollover the funds to an IRA. I thought, “It will be fine. I’ll wait until they finish setting up the new record keeper. Then, I can do the rollover.”

When the blackout period was about to end, I didn’t receive any instructions about the new record keeper. The funds had been transferred already and I called the old record keeper to confirm it was done by my former employer. I think, “Maybe they forgot to contact me because I’m no longer an employee.”

I email HR and ask when I can expect instructions on how to access the new record keeper. Idiots send me instructions for the old record keeper and how to file for a distribution. HR had actually called the old record keeper for these instructions when the funds were no longer with the old record keeper. WTF 😤

It takes all of my strength to write a civil email. I remind them that funds were transferred nearly 2 weeks ago by them to a new record keeper. I repeat that I need instructions on how to access the new record keeper and I don’t need instructions on how to file for a distribution from the old record keeper.

I’m effing glad I don’t work there anymore. I can’t deal with that HR’s idiocy anymore.

Marketing Person: [email] The feature you worked on is setting our customers’s statuses to “transactional.” We can’t send them marketing emails.

😒🙄

Me: [email] My code is not doing that. It checks to see if a contact exists in our mailing list. If it does, it adds the contact to the new list that you requested. If it doesn’t, it creates a contact and adds it to the list. Newly created contacts default to “onboarding.” For already existing contacts, I’m just adding them to the list and I’m not changing anything else. Here’s a blog post from the marketing software company that explains how a contact could get marked as “transactional.”

Later in the day, Marketing comes over to my desk and brings over the Product Manager. He asks the same question. 😡 Oh hell no. You do not create a gang up on me and hope the social pressure changes my answer.

Me: Like I wrote in my email, my code isn’t wrong and it’s not malfunctioning. It’s doing what you requested: add users who submit their email on x form to the new x list. In the marketing software, you can even check each contact and see when their status got changed to “transactional.” It wasn’t from my code.

I really hate marketing sometimes. Especially when they think they know how my code works. Excuse me, do you have access to our git repo? Can you read the code and point out the supposed problem? I didn’t think so. So don’t go accusing me of making a mistake or doing my job wrong.

FUCKING STACKOVERFLOW ASSHOLES.

This guy answered my question on security.stackexchange.com with an answer showing he clearly doesn’t understand that I’m asking if my RAID1 setup constitutes an appropriate backup. (I know that sounds stupid, I can post a link if anyone wants to see the specific circumstances).

I FUCKING KNOW RAID ISNT A BACKUP BUT THIS GUY IS LIKE “RAID 1, or mirroring, is definately [sic] considered a backup in corp IT”

Go suck a dick.