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

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

121–130 of 704 posts

Re: Software engineering topics I changed my mind on

#121

Post by username90 »

foolfoolz wrote: post #55

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. it’s unfortunate you haven’t had the opportunity to work with a strong product team. i agree when they are not helpful it’s a negative impact on the team. but a great PM can elevate everyone who develops that product

> it’s unfortunate you haven’t had the opportunity to work with a strong product team.

He said that 10% were useful, not that all of them were bad.

Re: Software engineering topics I changed my mind on

#122

Post by hertzrat »

> People who stress over code style, linting rules, or other minutia are insane weirdos

Really great post, although I do really value good, consistent code style. Readability really matters (imho). You can even use writing concepts like parallelism if you are feeling fancy to make things even easier to read.

Re: Software engineering topics I changed my mind on

#123

Post by smallnamespace »

danfang wrote: post #113

I agree with most of the points the author makes. > Pencil and paper are the best programming tools and vastly under used I'm not convinced of this one. I grew up with digital tools only. Can someone give me examples where this assertion is true?

System diagrams.

I've never drawn seen anyone draw a system diagram using any tool more quickly or better than they could on the back of a napkin.

If you start from the get-go trying to wrangle a UML diagram or Lucidchart, then your mind is immediately guided to do only the things the tool makes easiest.

That's why when you're inventing something from scratch, a pencil and a piece of paper are best. Of course, if your handwriting is messy, go back and use a tool later for your colleagues' sake.

Re: Software engineering topics I changed my mind on

#124

Post by dathinab »

baby wrote: post #44

> YAGNI, SOLID, DRY. In that order. What? > Java isn't that terrible of a language. Doesn’t mean it’s a good language though. > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers And when people ask for numbers, it is usually because they don’t like your idea > People who stress over code style, linting rules, or other minutia are insane weirdos That’s why y…

> I admit I still don’t understand what a PM really does.

In the best case they have a proper technical understanding and do ground the team in reality (i.e. makes sure the team doesn't over analyses/engineer and adds fully unnecessary part).

Then the PM should help the team to come to decisions if the team can't decide weather they do solution A or B and they _seem_ to be equally good wrt. all measurable and non measurable aspects.

Lastly the PM should help to keep all the unhelpful and hinder-some things upper management might want to put on the engineering team away and similar thinks.

The problem is the PM needs IMHO solid technical understanding of the topic in question at the same time they need enough soft skills to nudge the team in the right direction and protect it from upper management absurdities.

I don't think I have yet to meat a person who fulfills this qualities, often they fundamentally lack technical understanding to a degree that they do more harm then good, i.e. in many cases a self managed team with a tech. senior team lead is a better problem. Except if the team lead is not grounded enough and prone to over-engineering, at which point a PM (or second team lead) to ground this person is essential.

Re: Software engineering topics I changed my mind on

#125

Post by free_rms »

ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

The linked post said project manager.

Good PRODUCT managers, in small numbers, are worth their weight in gold IMO. Researching/talking to users takes time, making decks takes time, stepping back and surveying the landscape takes time. It's worth having someone doing that.

Re: Software engineering topics I changed my mind on

#126

Post by dathinab »

dathinab wrote: post #124
baby wrote: post #44

> YAGNI, SOLID, DRY. In that order. What? > Java isn't that terrible of a language. Doesn’t mean it’s a good language though. > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers And when people ask for numbers, it is usually because they don’t like your idea > People who stress over code style, linting rules, or other minutia are insane weirdos That’s why y…

> I admit I still don’t understand what a PM really does. In the best case they have a proper technical understanding and do ground the team in reality (i.e. makes sure the team doesn't over analyses/engineer and adds fully unnecessary part). Then the PM should help the team to come to decisions if the team can't decide weather they do solution A or B and they _seem_ to be equally good wrt. all measurable and non mea…

> lead is a better problem

A typo, but honestly it interesting to thing what I could have meant with it even for myself so I won't fix it ;-)

Re: Software engineering topics I changed my mind on

#127

Post by danfang »

sanderjd wrote: post #77
woeirua wrote: post #62

The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

The reality is that companies at an early stage don't have validation of their idea yet. That is priority #1. The scaling part comes only after you know your idea has merit. It's also "the easy part". With the right allocation of resources and talent, most scaling challenges can be solved. The same cannot be said of creating valuable / interesting products.

The right approach is to optimize for speed and flexibility. Make it as easy as possible to validate your idea. Make it easy to tear down and rebuild in a "scalable" way if you're lucky enough to make it past step #1.

Re: Software engineering topics I changed my mind on

#128

Post by marcinzm »

01100011 wrote: post #81
ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in…

>A PM keeps management apprised of progress.

In most places, project managers save managers time by not requiring managers to spend their time figuring out the progress of things. However because PMs have more bandwidth they take up even more engineer time than managers would.

Re: Software engineering topics I changed my mind on

#129

Post by mlthoughts2018 »

coldtea wrote: post #84
mlthoughts2018 wrote: post #28

The author of this seems like a real joy to work with > “TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.” Imagine thinking about colleagues as people with “frail little minds.” Yikes. Many of the other points betray serious attitude and perspective problems, but it was forgivable until getting to that last bullet and realizing, no, this is just a person wit…

> Imagine thinking about colleagues as people with “frail little minds.” Yikes. He's not thinking about ALL colleagues, but "TDD purists". And even so, it's obviously a turn of phrase to dismiss the hardcore purism, not something the author generally feels about such people in their entirety.

Absolutely not. Setting up a strawman “absolute purist” (and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this) and then using needlessly insulting or belittling language to condemn the fake strawman is totally ridiculous. Your attempted defense of it is not acceptable.

You could just as easily say something like, “People who take TDD to an extreme are hard to work with and ultimately their inflexibility and unwillingness to appreciate other approaches does more harm than good.”

See how that’s not dehumanizing? See how that accomplishes the same thing without disgusting juvenile insults like saying someone of a different ideology has a “frail little mind”?

Re: Software engineering topics I changed my mind on

#130

Post by dathinab »

t-writescode wrote: post #49
naikrovek wrote: post #48

> So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot That's the truth. "Best Practices" often force you to ignore what your problem actually is and view it in some twisted way that fits the practice. Bad. Your problem is your problem. Your data is your data. Write code that matches what you have and what you're trying to do.

My biggest frustration around ‘best practices’ is when you’re tasked with learning a new framework to consider adopting it for the company and you’re given a week and they want ‘best practices’ to come out of it. There is no way I can learn how to write good code in a completely new framework that everyone should model after from that. I can show what worked for a toy problem and something that’s hypothetically simil…

> learning a new framework to consider adopting

The best practice is to not learn a new framework. Only learn the new concepts (technical and UX, if there are any) and if there is no noticeable benefit do continue using old framework.

In many cases new frameworks do not bring improvements to a degree that switching is worth it. They often do either obfuscate it or don't realize it themself, but most new frameworks do not invent any new concepts, they just dress existing (often old) concepts in new clothes. Which sometimes _can_ be a major improvement of UX but very often are not.

Post reply on HN