➡️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

You know that feeling when a non-techie decision maker understands you and makes the right calls? Nah, me neither.

Best:Working for people with money and crazy projects in mind. Working for dreamers. Working for people that believe in you, as a decision maker, stack choices. Choose not to be a pawn.

Worst: not leaving a company when they indiscriminately lie in the job offer. HR will never say bug fixing (that's like going to a date saying you have a micropenis from the beggining), they will say integrations, product improvement... If then all the tickets are bug fixing i should have said something in the first month.

When your company is sinking, and you keep suggesting to pivot, trying something new or different enough, having some meeting to think about new levers to increase revenue... and the only answer is "we don't have enough time for this. Let's try tweaking <insert random feature here>".

WE ARE LOSING 30.000€+ EACH MONTH!!! WHO FUCKING CARES ABOUT CHANGING THIS FEATURE NOW!!!

Today it's been more than 7 months since "we don't have enough time". Still nothing intelligent has been tried. The company could be closed down in 2 month. FUCK YA ALL decision makers!

Now I'll probably lose my job just because you're too fucking stupid to get your finger out of your ass! The company is in the exact same state since 7 months!!! Go burn in hell!

Caller: Hi, I work with Google. Can I talk to the decision maker of [your company]?
Me: I am. (Ho, my god, this is finally happening, I'm the chosen one!)
Caller: Would you like to improve your visibility on Google by ...
Me cutting short: Thanks but I'm not interested.
*Click*
To myself: Raaah, me too I work "with" Google!

(no my phone doesn't do *click*, it does *bee doooom*, but well)

Submitted my first proposal for a freelance gig and didn't win the bid but I don't feel bad about it. Asked for feedback and it turns out I lost because the dev who they chose had a recommendation from someone the CTO (decision maker) highly respected. He loved my proposal and appreciated my efforts on it and my bid was marginally lower than the dev they chose.

Overall it was a positive experience and I may have established a good report with the CTO in the process.

So I figure since I straight up don't care about the Ada community anymore, and my programming focus is languages and language tooling, I'd rant a bit about some stupid things the language did. Necessary disclaimer though, I still really like the language, I just take issue with defense of things that are straight up bad. Just admit at the time it was good, but in hindsight it wasn't. That's okay.

For the many of you unfamiliar, Ada is a high security / mission critical focused language designed in the 80's. So you'd expect it to be pretty damn resilient.

Inheritance is implemented through "tagged records" rather than contained in classes, but dispatching basically works as you'd expect. Only problem is, there's no sealing of these types. So you, always, have to design everything with the assumption that someone can inherit from your type and manipulate it. There's also limited accessibility modifiers and it's not granular, so if you inherit from the type you have access to _everything_ as if they were all protected/friend.

Switch/case statements are only checked that all valid values are handled. Read that carefully. All _valid_ values are handled. You don't need a "default" (what Ada calls "when others" ). Unchecked conversions, view overlays, deserialization, and more can introduce invalid values. The default case is meant to handle this, but Ada just goes "nah you're good bro, you handled everything you said would be passed to me".

Like I alluded to earlier, there's limited accessibility modifiers. It uses sections, which is fine, but not my preference. But it also only has three options and it's bizarre. One is publicly in the specification, just like "public" normally. One is in the "private" part of the specification, but this is actually just "protected/friend". And one is in the implementation, which is the actual" private". Now Ada doesn't use classes, so the accessibility blocks are in the package (namespace). So guess what? Everything in your type has exactly the same visibility! Better hope people don't modify things you wanted to keep hidden.

That brings me to another bad decision. There is no "read-only" protection. Granted this is only a compiler check and can be bypassed, but it still helps prevent a lot of errors. There is const and it works well, better than in most languages I feel. But if you want a field within a record to not be changeable? Yeah too bad.

And if you think properties could fix this? Yeah no. Transparent functions that do validation on superficial fields? Nah.

The community loves to praise the language for being highly resilient and "for serious engineers", but oh my god. These are awful decisions.

Now again there's a lot of reasons why I still like the language, but holy shit does it scare me when I see things like an auto maker switching over to it.

The leading Ada compiler is literally the buggiest compiler I've ever used in my life. The leading Ada IDE is literally the buggiest IDE I've ever used in my life. And they are written in Ada.

Side note: good resilient systems are a byproduct of knowledge, diligence, and discipline, not the tool you used.

So, I am fresh CS grad working at his first dev job at a pretty small startup (less than 20 people).
The Engineering team has 7 people and it's relatively flat.
At times, the senior engineers in my team, have 1:1's with the CEO and (what I feel is) some decisions are taken according to that meeting.
I feel kind of uncomfortable about this secrecy etc. even though I know that at least right now I am not experienced enough to be a "decision-maker".
Is this normal? Idk if this is how politics in the workplace happens.. looking for advice on what I should do regarding this..
Also, it doesn't help that I am literally the only Software Engineer (all other Engineers are Senior Software Engineers or CTO) so there is this generational gap which has limited my ability to "really connect" with anyone on the team.

I'm tired. I don't want to do these tests anymore. These vague test scenarios I have to decrypt on my own lest asking business shows signs of weakness. I'm slow to test and going way beyond the hours the client estimated and you folks just accepted. How can I finish this when I get pulled to meetings which I am not the decision maker but I'm supposed to be the technical one to help them decide. In between this testing I get emails to help check on issues I'm not even a part of. Production issues I can understand because those have a feel of critical and priority but if you pull me to that I lose time testing. I'm trying. But I'm truly very slow at this. I'm a slow tester for this set of test cases. I'm hating myself every minute as the hours inch to the deadline which is today. I want to sleep but I want to finish as well. Shitty days of drone work that could have been given to somebody else but I can't say no to because you guys accepted. Someone from management just see please, don't give this to me. But you can't see. You probably don't even understand. They asked, you caved because you can't see the list of tasks and level of detail that comes with each thing they ask. This testing is a ridiculous use of my time but I can't say that to the client. You could have. I want to. I truly want to say "Fuck these tests". I tried to push back. But the client of course reasoned back and it was understandable to ask. To do what's good and what's best. How can I say no to that?! I'm almost depleted. I'll just finish this somehow.