Live data from Hacker News

Things they didn’t teach you about software engineering

vadimkravcenko.com

171–180 of 285 posts

Re: Things they didn’t teach you about software engineering

#171

Earlier quoted context omitted.

Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes.…

> It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. I'm not. I didn't say anything about speed. I am talking about deciding what to build. All of your examples lack the context of what is the best at making money for the business. You can't properly make a decision about addressing any of tho…

My mind jumps to things like..

- Don’t rewrite the architecture with microservices when the monolith is working fine

- Avoid rebuilding the company blog on the latest CMS unless there are good business (time/money) reasons to do so.

- Choose boring technology, which would be the ones that most of the people on the team already know, and probably not the cool new language you heard about last week. Avoid fragmenting the tech stack to keep things operationally simple.

This is just a guess though – if you have some examples from your own experience it would be great to hear about some!

Re: Things they didn’t teach you about software engineering

#172

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

I disagree with both.

Code and business value are worthless. Boss approval is literally everything.

It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. Damage to ego means get that guy out of here and make sure I don’t hear more from them.

People need to understand that you’re hired for a job. You’re a glorified and well compensated code monkey. Even at $1m/yr - still a god damn code monkey. You jump when they say jump.

I’ve yet to meet any hierarchy chains that are truly open minded to a low level IC saying anything that counters them. I’ve worked at quite a few places too and talked to a lot of folks about this.

You’ll thank me in ten years because you’ll become a bootlicker and actually make progress in your career rather than being stuck in senior/staff until you burnout from the industry.

Re: Things they didn’t teach you about software engineering

#173

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

I disagree with both. Code and business value are worthless. Boss approval is literally everything. It really doesn’t matter if your ideas make a ton of business sense if they are in conflict with your direct manager or any part in the chain of hierarchy. As long as they don’t like what you’re saying - you’re literally worse than worthless. Often this is because your idea isn’t their idea - therefore damage to ego. D…

This is the real answer. Ego is greater than business, money, and code.

Re: Things they didn’t teach you about software engineering

#174
post #170

Earlier quoted context omitted.

Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes.…

> Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features. Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth. Performance is a r…

> Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.

Honestly I have yet to use a significant (like >10k line) Python app that wasn't really slow. It definitely doesn't require YouTube scale.

"Just optimise the bottlenecks" is generally a myth in my experience. Most programs are all bottleneck.

Re: Things they didn’t teach you about software engineering

#175

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

money is not the goal. providing a useful and valuable product or service to customers is the goal.

There is so much packed into the phrase "the goal."

- Is it the business owner's goal? Depends on the business owner.

- Would the CEO have a better company if they focused on building something great rather than extracting money? Depends on the industry (the premise of capitalism is yes, but unfair markets are a thing)

- Is it (betterment of society through engineering) a valid personal goal to have on a strictly moral or ethical level, with no need of evidence or efficacy? Sure, absolutely

- Are people who focus on "extracting money" sheisty MBA types who lie through their teeth and exaggerate every number and kill the company in the process of trying to self-promote any random thing they can control? Sounds like a leading question...

These are all worthy distinctions imo.

Re: Things they didn’t teach you about software engineering

#176

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

I learned this at some point while working in manufacturing. No one responsible for how much you get paid really cares how clever your idea is unless it makes the company more money. For me, the game theory gets pretty advanced at this level. My strategy now relies on enriching myself via equity and careful product decisions so that I can then go start my own software studio and do things my way. Presumably, this is…

The irony is, I started and sold a consulting business. We got to do some things our way, but we still had to make money. Overall, I say do it, but I made choices I never imagined I would have to make. So it goes.

Re: Things they didn’t teach you about software engineering

#177

Earlier quoted context omitted.

I've worked with multiple german companies that declared their programmers as engineers, "Jr/Mid/Sr Software Engineer" or the more focused "Frontend/Backend/Fullstack Software Engineer". Maybe that's more of a thing in agencies? But then I think SAP calls them "Software Engineer" as well.

I suspect this is mainly because the whole hiring process has been internationalized, and 'Software Engineer' seems to have become the common international phrase for 'anybody who has the ability to author software'. 15 years ago it would have been "Softwareentwickler" or "Programmierer" (optionally with the requirement of a degree in computer science, which - funny enough - also isn't excplicitely called a 'science'…

I wouldn't put too much thought into the naming, "informatics" in Germany is still a Bachelor/Master of Science and on the other hand at Stanford they have a "Mathematical and Computational Engineering" programme.

Re: Things they didn’t teach you about software engineering

#178

Pretty decent article (don't agree with everything, but for the most part) > Code is secondary. Business value is first. I wish I could shout this from a mountaintop. If there's one thing I could change about engineering culture it would be this. But then again I would lose my edge if everyone understood this, so maybe it's best that they don't Engineers: If you want to stand out in your career - take this to heart.…

Depending on what you mean by "code" I disagree. It sounds like you're arguing for "just get it done quickly" vs "take your time and do it right". That isn't a "code vs money" debate it's short term vs long term productivity. Technical debt is a real thing. As is "decision debt" (not sure the official term; I mean where you make the wrong long-term choice because you didn't spend enough time on research / prototypes.…

And sadly those aren't problems or concerns for many/most folks. It's only an issue for those that haven't moved on after 2-5 years. Sad but true. Short term thinking is our present reality and way of conducting "business".

Re: Things they didn’t teach you about software engineering

#179
post #66

Earlier quoted context omitted.

Because there is a very strong negative correlation between overworking and productivity / quality of work. When I've been line managing people I find that if they work over 40-45 hours a week their actual productivity (as opposed to their self perceived productivity) starts to fall off a cliff after a couple of weeks, so I ask people to only work their hours. I've sometimes had to implement technical measures to enf…

> Because there is a very strong negative correlation between overworking and productivity / quality of work Working outside of business hours is not the same as overworking. I have some days packed with meetings and calls, and I actually find it refreshing/relaxing to work on more down to earth matters in the evenings or weekend. Sometimes I even take vacations just to code on some work-related projects that I find…

You’re either:

- management pretending to be a wagie as a psyop

- extremely privileged and never had to grit your teeth to pay the bills

- going to have a rude awakening when the crop of younger millennials and Gen Z hits your workplace and you realize these bright young things with dreams and desires are only in software because it’s one of the few lucrative careers left in this proto-fascist shithole of a dying civilization.

Re: Things they didn’t teach you about software engineering

#180
I do not at all agree with the "it's not a dream job" section.

Please name another career that pays you six figures out of college that doesn't involve several years of additional education, doesn't make you wear suits, is mostly non-life-threatening, is constantly in demand, and doesn't require special accreditations or certificates.

If you're spending more than your 40 working and aren't on call, then that is on you 90% of the time, in my experience. I have definitely worked more than 40 some weeks when I'm pushing through something, but there have been plenty of times where I worked less.

If you can't find advancement in your current role, then that's also on you. Not that this matters, as finding a new job in this industry is insanely easy relative to other professions, and they'll usually pay more for your skills.

IMO, you should ALWAYS be thinking about what you need to do to get to the next level, if career advancement is a priority. Everything you do should be in service to demonstrating capability in performing above your station and providing business value/revenue generation. Brag sheets and being vocal help a lot.

I am biased; I absolutely love what I do and wouldn't trade it for anything.

Post reply on HN