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

591–600 of 704 posts

Re: Software engineering topics I changed my mind on

#591

Post by dijit »

dagmx wrote: post #586
dstola wrote: post #554

Earlier quoted context omitted.

Politically incorrect opinion incoming: the most efficient teams are homogeneous for the same reasons that military battalions are best off being homogeneous. 1. it improves communication 2. shared experiences and culture 3. overall better team cohesion and culture building I would go almost as far as saying that diversity is a red flag for a startup and that diversity starts to have benefits only in bigger companies

This has to be one of the most outright bigoted posts I've seen on HN. It implies that only outright homogeneous cultures are good. So a white woman is a negative to be in a work culture with a white man, because she cannot relate to being a man? Or a black man can't work with a white man because he can't relate to being white? Or do you mean if I'm from a foreign country, legally allowed to work in America, that I a…

To be perfectly fair with the parent; It _is_ a very western ideal about heterogeneity being highly valued.

I think tying emotions to it does us little favours - a prominent successful country that does not value heterogenity at all is Japan.

Does Japan outcompete per capita?

(The answer is no).

Not sure if there are other examples of note here.

Re: Software engineering topics I changed my mind on

#593

Post by hallway_monitor »

Interviewing is mentioned. I'm currently doing a lot of that and I agree it's challenging to assess engineering skill. We currently use a fairly simple coding challenge that shouldn't be a problem for anyone with some experience. We basically pair program with them for an hour or 90 minutes (remotely for now) to see how they work through problems and write code. It has been pretty successful so far.

Re: Software engineering topics I changed my mind on

#594

Post by recursive »

jawns wrote: post #499
xxs wrote: post #407

Earlier quoted context omitted.

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

It's easier to find devs who know basic SQL than it is to find devs who know pandas or whatever your language specific SQL-like library is. And the more complicated the queries, the more the gulf widens.

I don't think pandas was the proposal here. I think "standard data structures" refers to arrays, hash tables, trees, and the like.

Re: Software engineering topics I changed my mind on

#595

Post by conradfr »

temporallobe wrote: post #150
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…

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 think it's the role of the lead dev to help newbies and coordinate work if needed. It can also be discussed at some meeting where the PO would present future tasks.

I don't see that as an intangible rule, it's all project and team dependent. And I see how in a remote world a "standup" can be beneficial.

Re: Software engineering topics I changed my mind on

#596

Post by bvirb »

woeirua wrote: post #528
sanderjd wrote: post #77

Earlier quoted context omitted.

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.

No, you should use proper abstractions to allow you to "easily" replace components down the road. There's no point in planning, designing, or building your application for a million users because by the time you get there: 1 - the business needs will be radically different from what you expected initially, and 2 - you'll have dozens more engineers who will probably do the actual work. It's exceedingly unlikely that t…

I find trying to decide on "proper abstractions" can also cause the same issue as trying to design for scale: you have to make complex design decisions based on how the future might turn out (which components might you need to replace? what might their future interface requirements be?).

I think it might be more efficient to do whatever is fastest/easiest based on what you know now & always plan on refactoring when you know more. So you end up trying to write less, simpler, code knowing you're going to tear it apart soon.

Which I think still fits with your overall point.

Re: Software engineering topics I changed my mind on

#597

Post by jugg1es »

specialist wrote: post #171
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 was on a team which used DynamoDB for their hottest data set. Which would trivially fit in RAM.

I've definitely had to push back on engineers wanting to use Redis for caching data they just pulled from the database. "Just store it in RAM guys..."

Re: Software engineering topics I changed my mind on

#598

Post by dstola »

dagmx wrote: post #586
dstola wrote: post #554

Earlier quoted context omitted.

Politically incorrect opinion incoming: the most efficient teams are homogeneous for the same reasons that military battalions are best off being homogeneous. 1. it improves communication 2. shared experiences and culture 3. overall better team cohesion and culture building I would go almost as far as saying that diversity is a red flag for a startup and that diversity starts to have benefits only in bigger companies

This has to be one of the most outright bigoted posts I've seen on HN. It implies that only outright homogeneous cultures are good. So a white woman is a negative to be in a work culture with a white man, because she cannot relate to being a man? Or a black man can't work with a white man because he can't relate to being white? Or do you mean if I'm from a foreign country, legally allowed to work in America, that I a…

Asking rhetorical questions of this nature is not achieving anything except airing your hurt sensibilities. People can have opinions other than the ones you hold and I already outlined fairly clearly in my original post what I think.

Heterogeneity is bad for startups because of the need to have no friction communication and shared goals/ideals/experiences. It does _not_ mean that diversity is bad in a big company or overall.

Re: Software engineering topics I changed my mind on

#599

Post by Geminidog »

I disagree with software architecture. There's not enough theory and science in organizing code and understanding complexity. Most of what goes on here is just guessing. If you created "good architecture" it only means future requirements happened to fit your design, aka you made a good guess.

Rarely does anyone design anything that is efficient in the present and adaptable to any possible future simply because there's no science and theory on how to design such a thing. There's some rules of thumb but even following these rules of thumbs people end up with technical debt most of the time anyway. It always happens, if a project lives long enough, more and more "design mistakes" made at project inception become evident.

I have personally found tacit programming to be the solution for this but because there's no theory I can't explain to you definitely why tacit programming is the best way to deal with tech debt of the structural nature.

Post reply on HN