Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things they didn’t teach you about software engineering

vadimkravcenko.com

Post reply on HN
Print view View original

191–200 of 285 posts

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

#191

Post by KyeRussell »

bitexploder wrote: post #176
bob1029 wrote: post #164

Earlier quoted context omitted.

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.

This is really the next layer up in the ‘galaxy brain meme’ of this thread. The understanding that the people that dissuade you from gold plated engineering solutions are not some inherently different monsters. Rather, they’re doing at least roughly what you’d do in the same situation.

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

#192

Post by pc86 »

FlyingSnake wrote: post #88
quanticle wrote: post #27

Rare work-life balance. In other professions, your work day ends at 18:00, and you forget about the job. Not here. You will most likely always be online and checking the code, even in the evening. If that's the case, quit immediately. I've been in this industry for over a decade (oh god, has it been that long already?) and I have never had a job where I was "always online and checking the code, even in the evening".…

I lead a fairly large team and I agree with this comment. It is certainly possible and healthier to disconnect from work after 17:00. Unless you’re in charge of coding a nuclear reactor core or similar, your CRUD app can always wait. A streamlined on-call process should be in place instead. Taking care of your headspace and unwinding at end of the day should be one of the most important routines in a programmer’s lif…

> A streamlined on-call process should be in place instead.

Honestly even 99% of non-nuclear reactor code doesn't need on call. Most of the time it can wait until the morning. Amazon? Sure, have on call. Your app that's used by businesses during the business day? Fix it tomorrow.

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

#193

Post by bitexploder »

KyeRussell wrote: post #191
bitexploder wrote: post #176

Earlier quoted context omitted.

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.

This is really the next layer up in the ‘galaxy brain meme’ of this thread. The understanding that the people that dissuade you from gold plated engineering solutions are not some inherently different monsters. Rather, they’re doing at least roughly what you’d do in the same situation.

It’s the central tension we always had. Can you do enough your way, and as you grow, your teams way while still making money. Hackers have an ethos and working for big corporate behemoths often means compromising that ethos. I feel we did, and still do, a good job. You can get rid of so much red tape, focus on quality, have a really fun culture etc. and if you hire pragmatic folks who accept they get all of that in return for doing the make money part of consulting it can be a ton of fun and very rewarding. But the owners and managers in the business are always balancing it.

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

#194

Post by sirsinsalot »

croes wrote: post #187
rco8786 wrote: post #138

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 the goal, code is a tool to get the money. You work in a capitalistic business, whether you like it or not. Pu Capitalism and money are actually only the means to an end, to achieve the best possible for society. But as is so often the case, at some point the means becomes the end.

As if capitalism in practice has ever been about the best outcome society wide.

It's about a means of allowing wealth disparity while the have-not masses are too distracted to get out the guillotine

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

#195

Post by Kamq »

IshKebab wrote: post #162
rco8786 wrote: post #138

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.…

> it's short term vs long term productivity

You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way.

There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career.

When you hit that 1/10 product, you will experience some pain. But you now have enough information to justify dumping the resources (including political capital) into a proper long term solution.

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

#196

Post by sirsinsalot »

fatneckbeard wrote: post #140
rco8786 wrote: post #138

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.

The only reason anyone can and does make a valuable product or service is for some wealth. If not money, kudos, power, ...

I don't buy the altruistic motives.

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

#197

Post by judge2020 »

quadcore wrote: post #106
renox wrote: post #51

Earlier quoted context omitted.

I rarely goes online in the evening but when I have an interesting problem, it's not rare that I have a solution when I wake up in the morning! So you don't really stop working at 6pm..

So you don't really stop working at 6pm.. I've started billing that. Not always, rarely in full, but I bill some of it. It's not just for the money but started more like "what exactly do I work? Best way to know is to bill it".

Unless you're a contractor, exempt salaried employees are exempt from overtime requirements and thus typically can't bill for overtime, unless their employer likes burning money for some reason.

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

#198

Post by bob1029 »

Kamq wrote: post #195
IshKebab wrote: post #162

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's short term vs long term productivity You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way. There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career. When you hit that 1/10 product, you will…

> When you hit that 1/10 product, you will experience some pain.

There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes.

Spinning hypothetical tales of doom in order to be granted permission to build something shiny is probably the #1 thing that slowed me down in my career.

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

#199

Post by IshKebab »

dceddia wrote: post #171
rco8786 wrote: post #168

Earlier quoted context omitted.

> 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 t…

Can't disagree with any of those really. I guess it's really hard to draw out general conclusions about these sort of things when the specifics really make a difference. You can pretty much say "spend your time wisely" which is not very actionable.

For instance on your last point - I've heard that used to argue against any new technology even if it solves real problems. Rust, Bazel, React, Typescript, etc.

I would go so far as to say some of these general principles can be harmful because they are mostly used as a lazy way to defend bad decisions. E.g. "premature optimisation" is more often used to justify ignoring performance entirely than it is to stop people writing things in assembly or whatever.

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

#200

Post by Kamq »

bob1029 wrote: post #198
Kamq wrote: post #195

Earlier quoted context omitted.

> it's short term vs long term productivity You should pick short term. Pretty much every time. The tradeoffs just don't make sense the other way. There's a 9/10 chance the thing you're working on will fail or not achieve any sort of scale. Opting for short term productivity will let you find this out faster, and save you millions of dollars and years of time over your career. When you hit that 1/10 product, you will…

> When you hit that 1/10 product, you will experience some pain. There is a neat little trick I learned. Wait until leadership is under fire from customers and/or investors regarding the thing you thought might become an issue, and then present your solutions. Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes. Spinning hypothetical…

> Once you have proper buy-in, you can likely move way faster than by trying to constantly side-channel things through existing processes.

I've noticed this as well. It's amazing how many road blocks an executive trying to save their reputation can clear for you.

Post reply on HN