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

531–540 of 704 posts

Re: Software engineering topics I changed my mind on

#531

Post by BurningFrog »

dirkt wrote: post #384
crescentfresh wrote: post #267

Earlier quoted context omitted.

> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.

status report = you have to take responsibility for what you have done (or not done) state what you are doing = what happens automatically if you sit in the same office with other programmers: you know what they are working on, you know if they are stuck with something because they usually just ask aloud, etc.

Not questioning your experience, but I've sat in a lot of engineering offices and had very little clue what the people around me were working on.

Standups really improved that aspect for me.

Re: Software engineering topics I changed my mind on

#532

Post by BurningFrog »

edumucelli wrote: post #481
temporallobe wrote: post #150

Earlier quoted context omitted.

Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…

I do not understand why people have to wait to discuss the blockers? Discuss a blocker whenever you have one.

If it can't wait, sure, ask for help right away.

But there are levels of blockers. Most are not emergencies.

Re: Software engineering topics I changed my mind on

#533

Post by GordonS »

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 good PM, yes.

But IME, most are not.

As a dev lead, tech lead or architect, my experience of PMs has almost exclusively been terrible. It has usually involved them being a thin proxy between myself and management, with the PM constantly pushing for firm numbers and dates, pushing for forecasts, asking for meetings to explain all of the things they have already been communicated...

I invariably end up feeling like a baby sitter, and feeling like I'm doing most of the work the PM should be doing, and with frequent, pointless meetings cutting severely into my available time. Aside from that, as soon as there is any pressure from the customer, the PM projects that onto the team, lambasting and pushing, pushing for more with less.

On occasion my experience is different, with the PM actually using the data they already have available in Azure DevOps (or whatever), keeping meetings to the minimum, and shielding the team from outside stresses. Very rare though.

Re: Software engineering topics I changed my mind on

#534

Post by busterarm »

xxs wrote: post #406
busterarm wrote: post #327

Earlier quoted context omitted.

ACID transactions, validations & constraints, and the ability to debug/log by dumping your data to disk which can then easily be queried with SQL. All of the same reasons you would store relational data in a dbms...

>ACID transactions, validations & constraints There is no D from the ACID. For the D to happen, it takes transaction logs + write barrier (on the non-volatile memory). Doing Atomic, consistent and isolated is trivial in memory (esp. in GC setup), and a lot faster: no locks needed. Validations and constraints are simple if-statements, I'd never think of them as sql.

You _can_ have forms of durability if you wish to. You can get "good enough" (actually fairly impressive...) performance for most problems (vs only in-memory) with SQLite making memory the temp store, turning on synchronous and WAL. Then fsync only gets called at checkpoints and you have durability at the checkpoint.

Re: Software engineering topics I changed my mind on

#535

Post by mathattack »

cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

I’ve seen similar issues where people got stuck on Mongo because it’s easy to install.

Re: Software engineering topics I changed my mind on

#536

Post by BurningFrog »

js8 wrote: post #368
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…

> 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 looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so t…

I think "agile practices" without pair programming misses 70% of the benefit.

If you're pairing, no one person becomes the only expert on something, and also no one person is left alone to solve all problems in an area.

Re: Software engineering topics I changed my mind on

#537

Post by busterarm »

xxs wrote: post #407
Falkon1313 wrote: post #387

Earlier quoted context omitted.

I think that depends on what you're doing with the data. If you're just grabbing one thing and working with it, or looping through and processing everything, maybe not. But if you're doing more complicated query-like stuff, especially if you want to allow for queries you haven't thought of yet, then the DB might be useful. Sometimes a hybrid of query-able metadata in a DB along with plain old data files is good. That…

>doing more complicated query-like stuff That's some kind of fallacy - standard datastructures would totally destroy any-sql-alike thing, if it comes to performance (and memory footprint). I guess it does depend on where the background comes when it comes to convenience - or how people tend to see their data. However like I said - for close to 3 decades I have not seen a single reason to do so. On the contrary I've h…

Performance is not god. It is not the altar at which we sacrifice all other considerations.

Re: Software engineering topics I changed my mind on

#538

Post by busterarm »

Falkon1313 wrote: post #379
busterarm wrote: post #199

Earlier quoted context omitted.

You've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.

Eh, not so much databases, but in terms of code, super flexible 'all things to all people' generic abstractions tend to be a lot more work and a lot more difficult to debug than a tight solution tailored to the problem it's solving, written in domain terminology. If only I had a nickel for every hour I've spent debugging abstractions and indirection that were just there for the sake of adding flexibility that would n…

I'm in agreement with you actually. I was badly suggesting that that kind of flexibility up front bites us in the ass later and it's a bad impulse often followed.

Re: Software engineering topics I changed my mind on

#539

Post by satya71 »

Solid list. I'll disagree this.

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

We use Black for Python, Prettier/Standard for Typescript. Code is readable across developers and there is no question about how it should be formatted.

Make this easier: > Clever code isn't usually good code. Clarity trumps all other concerns.

Re: Software engineering topics I changed my mind on

#540

Post by piggubiggu »

xxs wrote: post #479
piggubiggu wrote: post #474

Earlier quoted context omitted.

It sounds like you're talking about toy databases which don't run at a lot of TPS. Let me point out some features missing from your simple load a map in memory architecture. You also have to do backup and recovery. And for that, you need to write to disk, which becomes a big bottleneck since besides backup and checkpointing there is no other reason to ever write to disk. Then, you have to know that even in mem databa…

>It sounds like you're talking about toy databases which don't run at a lot of TPS. The original talk was explicitly about SqlLite and in-memory databases, no idea where you got the rest of.

Correct. So we're talking about in memory databases like MongoDb, and all of the things I listed here are true about MongoDb. For example, MongoDb migrated their database memory manager away from mmap and towards a custom memory manager (point being that gc and memory management for databases is not something you can just use jvm or operating system constructs for)

https://docs.rocket.chat/installation/docker-containers/mong...

I'm happy to justify every single point I made with research papers.

Lastly I know I came off as a bit condescending. Just having a bad day, nothing personal. But you should read more about in mem dbs.

Post reply on HN