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

301–310 of 704 posts

Re: Software engineering topics I changed my mind on

#301

Post by rebeccaskinner »

jackfoxy wrote: post #253

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful,…

In a lot of cases Microservices are the cheaper option. Keeping your code in a monolith requires a lot more investment in tooling (to manage a large monorepo, because apparently our industry has collectively forgotten that you can actually build separate libraries and keep them in different repositories) and coordination between multiple teams working on a single large project. The simplest solution is often for management to throw their hands in the air and let each team stake out their own territory and own their own services. You certainly pay a cost for it in terms of overall infrastructure complexity, but maybe if you're lucky you get some resilience and scalability out of it.

Re: Software engineering topics I changed my mind on

#302

Post by era86 »

bshoemaker wrote: post #141

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I never cease to be surprised when an otherwise intelligent person lays judgment on something they likely do not understand. At larger companies, these types of roles are invaluable. I'm going to charitably that this isn't referring to product management - it's dumb either way though.

This developer only has about 6 years of experience working at Amazon. It seems surprisingly naive how little this person understands about what a decent PM shields them from as an engineer, but I've heard working at Amazon sucks altogether. So, par for the course?

Re: Software engineering topics I changed my mind on

#303

Post by akdas »

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements to be made.

Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds, acknowledge the best developers are not the best interviewers (both as candidates and interviewers), and put in the extra effort to hone our interview skills. At an organizational level, I'm working on training material that I hope to promote within companies that are interested in improving their hiring process.

Interviewing is thoroughly broken. But I have some ideas to make it better.

[0] https://hiringfor.tech/archive.html

Re: Software engineering topics I changed my mind on

#304

Post by arbalist »

axaxs wrote: post #212
pseudalopex wrote: post #202

Earlier quoted context omitted.

It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.

Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people. If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted. There's zero reason that teamwide changes can't be proposed for discussion via email or slack.

It doesn't take domain knowledge to take responsibility for improvement. If your retros are taken up by lamentation maybe you should try to bring more focus.

Re: Software engineering topics I changed my mind on

#305

Post by vmception »

beagle3 wrote: post #288
vmception wrote: post #224

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql I use NoSql because RDBMS is a premature optimization for me My experience with ORMs especially ORMs I didnt chose is that they are frail, assume too much and I often end up writing my own plain text queries anyway, all so that I can get a result from the database in object form, but without bogging down the data…

The problem you point to is the ORM, not the DBMS. And if you think “of course, but how can you OOP properly without objects? (And thus ORM if you use an RDBMS)” — you might join some of us in the conclusion that OOP is way overrated. Don’t get me wrong, it is exceptionally useful when it’s a natural fit, like in GUI systems and some aspects of game programming. But in many places, it is completely unfitting, and com…

My point is that I dont need to do plain text queries or need to make queries simpler or worry about what I just did to a row when I am using NoSql

Whereas I have all those concerns with DMBS, the ORMs want to help but just add more problems

Re: Software engineering topics I changed my mind on

#306

Post by hvasilev »

illustriousbear wrote: post #297

Another low effort blog post that Hackernews readers have upvoted because it says obvious things that they agree with. Quality on blog posts and articles is taking a bit of a dip lately.

I agree. There are maybe 1-2 articles a day that are really worth reading here. I skim the rest.

Re: Software engineering topics I changed my mind on

#307

Post by jbay808 »

rektide wrote: post #213
windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

> Standups are useful for communication between a team in general, if kept brief. Just once I'd like to work for a company that tries to stay in communication without so many explicit/manual/sync check-in gates. * No stand-up, engineers required to write a 250-words or less blog post 2+ times a week. * No announcing PRs, reviews &c to each other. Make watching the board a habit, one you "pull" rather than that is pus…

A place I used to work had engineers documenting their work essentially in the form of a blog. It was actually really a useful habit, and reviewing the project blogs once each week made it really easy for me to find cases when I could help a colleague who was working on something I'd had experience with before.

Re: Software engineering topics I changed my mind on

#309

Post by throw14082020 »

At my company, we have a stand up with Between 15-20 people. Personally, i think everyone is kind of disengaged, and nobody really knows each other. Everything is done remotely obviously because of COVID. The founder believes in working together in the office, so remote working may not be embraced.

So I would add what I learnt to the list: Keep stand ups small, between people who are actually working together on a specific problem/ product.

Re: Software engineering topics I changed my mind on

#310

Post by quelltext »

ng12 wrote: post #283
quelltext wrote: post #233

Earlier quoted context omitted.

This! Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc. Yet, the product manager position isn't really staffed, and neither is the project manager one. So, all the additional work beyond design and coding also falls on the owning engineer. And since we are frugal that engineer is happy to get maybe 1 additional engineer assigned to help. But…

> Where I work there's lately been so much additional process, planning, keeping stakeholders and dependencies up to date, etc. This is why I like the way the linked article put it: you can lose most PMs without sacrificing efficiency. I would imagine a great deal of this stuff isn't actually important and only hampers the team's velocity. A PM will make it their job to make sure it gets done, if there is no PM the u…

> A PM will make it their job to make sure it gets done, if there is no PM the unimportant stuff will fall by the wayside.

You will always need to spend some time project managing your project even when things are not as process heavy.

You still need to make sure that timelines are met or flag if they are not. Keep dependencies informed, push/remind other teams you depend on to fix a bug, add the feature they promised. Communicate with management to get more resources, etc.

A PM can do all of those things with a bit of input once in a while from engineers.

These things only aren't important if you neither have timelines to meet, have no dependencies, and aren't accountable for the success of your project. Outside a hobby project outside work I'm not sure we ever have that luxury.

The article doesn't talk about other roles, so maybe where OP worked these things would have been assisted by other roles, e.g. the product manager. Maybe from that perspective it's not clear to the engineer what value project managers provide but I feel it's a bit of a limited perspective to say a role that can dedicate their time to tasks of type X isn't of benefit to those who'd otherwise need to do these tasks.

I mean would you say the same about customer support? About getting clarity on compliance/legal/finance (via asking external council)? About internal developer tooling? There's a point where an engineer working on a product may need to do all these things in addition to the building. But you cannot claim that it'd make no difference to the engineer's efficiency if they could delegate those things to others.

Post reply on HN