Software engineering topics I changed my mind on • Hacker News Board

Re: Software engineering topics I changed my mind on

#681

Post by Shorel » Mon, Jan 25, 2021, 3:30 PM UTC

kettro wrote: post #231

zbobet2012 wrote: post #207

Earlier quoted context omitted.

I disagree. The best medium is a whiteboard or a blackboard :p. (Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).

To this end, I have a small, paper-sized whiteboard that I can scrawl onto on hands at all times. I bought a couple packs of the ultra-fine expo markers, and it’s been a boon. Great for quickly noting things down that don’t need to last. Having both is important, though: you need to be able to preserve the things that matter, that you may need later on.

You can use the rocketbook app. No need to buy the notebook.

https://getrocketbook.com/

Re: Software engineering topics I changed my mind on

#682

Post by jackfoxy » Mon, Jan 25, 2021, 3:58 PM UTC

mint2 wrote: post #663

jackfoxy wrote: post #653

Earlier quoted context omitted.

It kind of boils down (for me) to choosing a strongly typed functional language and relational database by default, justified by the theory behind those. I can be convinced, by myself or others, that a particular project calls for something else. Because I'm familiar with them and satisfied with the tools my defaults are F# and SQL Server.

Wait so are you saying that all that terms like predicate calculus and algebra boil down to in practical terms is use a strongly typed language and and relational database? Okay so aside from choosing databases and languages, do these concepts explicitly come up in day to day programming or are regularly thought about?

It's more like I don't need to think about these things. F# gives you immutability by default (but let's you use it if you really need it for a more efficient algorithm) and eliminates nearly all null values. Nulls can still leak in from an RDBMS. Working in an environment like this gets you to if it builds, it works (once you get used to FP thinking). You have to experience it to believe it.

Re: Software engineering topics I changed my mind on

#683

Post by randomswede » Mon, Jan 25, 2021, 3:59 PM UTC

xorcist wrote: post #573

Joeri wrote: post #328

Earlier quoted context omitted.

The idea is that you can scale different parts of the system at different rates to deal with bottlenecks. With a monolith, you have to deploy more instances of the entire monolith to scale it, and that’s if the monolith even allows for that approach. If you take the high load parts and factor them out into a scalable microservice, you can leave the rest of the system alone while scaling only the bottlenecks. All of t…

> you have to deploy more instances of the entire monolith to scale it, That's a common argument for microservices and one that I always thought was bunk. What does that even mean? You have a piece of software that provides ten functions, running 100 instances of it in infeasible but running 100 of one, 50 of three and 10 of six is somehow not a problem? That must be really the perfect margin call of some vsz hungry…

I have seen multiple production systems, in multiple orgs, where "he monolith" provides somewhere in the region of 50-100 different things, has a pretty hefty footprint, and the only way to scale is to deploy more instances, then have systems in front of the array of monoliths sectioning off input to monolith-for-this-data (sharding, but on the input side, if that makes sense).

In at least SOME of these cases, the monolith would've been breakable-up into a smaller number of front-end micro-services, with a graph of micro-services behind "the thing you talk to", for a lesser total deployed footprint.

But, I suspect that it requires that "the monolith" has been growing for 10+ years, as a monolith.

Re: Software engineering topics I changed my mind on

#684

Post by crescentfresh » Mon, Jan 25, 2021, 4:20 PM UTC

paledot wrote: post #518

lordgrenville wrote: post #394

Earlier quoted context omitted.

I would suggest the difference is if you feel pressure about your response. Is it ok to pass, or say something like "still working on same issue I discussed a couple of days ago"? If not, it's less like a casual conversation, and more like justifying your time.

I would say that's perfectly okay, but not for the reason you think. If your status is "still working on the same issue", your team should respond with "how can we help?". If your status doesn't change, that's a sign that something's wrong at some level, whether it's because you're stalled or because the issue was poorly scoped or poorly defined.

> your team should respond with "how can we help?"

this would kill the meeting at my company, it would go off the rails as a thing that everyone is present for and listening to. Moving it "offline" - as is often done - only occurs once it has gone sufficiently off the rails in the first place. Not saying there's anything wrong with this process, just pointing out it's counter to the "keep it short" discussion happening in this thread.

Re: Software engineering topics I changed my mind on

#685

Post by tjalfi » Mon, Jan 25, 2021, 6:41 PM UTC

lillecarl wrote: post #465

mabbo wrote: post #456

Earlier quoted context omitted.

> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…

What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?

> What is the upside of a highly diversified workforce?

It's harder to fail to cover use cases that the development team isn't aware of.

One example of this is name changes. Many products neglect this use case even though it's common[0] for women to change their family names after marriage.

[0] https://www.bbc.com/worklife/article/20200921-why-do-women-s...

Re: Software engineering topics I changed my mind on

#686

Post by KoenDG » Mon, Jan 25, 2021, 9:23 PM UTC

Always found the concept of "code coverage" to be a weird phrasing of what's actually happening.

The whole point is to answer the question: do your unit tests walk all possible paths in your code?

Now, the whole point of unit tests is to verify code behavior. See if it remains consistent if you change something somewhere, that kind of stuff. Don't want the new hire to make a well-intended change that ends up breaking things. This is why unit-tests exist. Amongst other things.

One may well write tests such that all possible code paths are checked... doesn't mean the actual code is performant or written in a clear manner, or written in a maintainable manner, etc...

I guess a better term would be "behavior coverage" or something?

Re: Software engineering topics I changed my mind on

#687

Post by montana399 » Mon, Jan 25, 2021, 9:57 PM UTC

https://www.tb42trk.com/5MX46D/6RGC42/

Re: Software engineering topics I changed my mind on

#688

Post by greyhair » Mon, Jan 25, 2021, 11:22 PM UTC

dvfjsdhgfv wrote: post #430

radicalbyte wrote: post #415

Earlier quoted context omitted.

I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / culture…

> * The root cause of the above is often insecurity; and it can be coached / cultured away. It's definitely not true. Very often the root cause of zealotry is simply passion, enthusiasm especially for something new you start to like more and more every day, and at some point you start to have a false conviction - that it could solve all possible problems. Usually, zealots become more reasonable with time.

In thirty five years, I have encountered three zealots that became worse over time, because their zealotry was seen by upper management as dedication and resolve, so they were rewarded. As we all know in engineering, positive feedback is bad. It was awful. But luckily only three times in thirty five years, so I have that going for me.

Re: Software engineering topics I changed my mind on

#689

Post by closeparen » Tue, Jan 26, 2021, 4:59 AM UTC

Chris_Newton wrote: post #312

tikhonj wrote: post #189

Earlier quoted context omitted.

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up . If something is important, why would you wait for tomorrow's standup? If something isn't important, w…

That seems like a reasonable concern to me, and something that could apply to almost any communications that are on a regular schedule, whether it’s a daily team meeting or an annual review with your boss. My father said something to me when I was nervous before my first annual review in my first job, and it has stuck with me ever since: nothing anyone says in that review should ever be a surprise . Whether it’s good…

When trying to schedule on an as needed basis, the next time slot where everyone is available together could be in several weeks. Especially if one or more participants are business types with impossible calendars. Standing meeting reserves a time slot and guarantees a topic can be discussed within N business days of becoming important. If there is nothing for the agenda that day then you cancel it and everyone gets some free time.

Re: Software engineering topics I changed my mind on

#690

Post by cccc4all » Tue, Jan 26, 2021, 7:56 AM UTC

wegs wrote: post #574

cccc4all wrote: post #236

Earlier quoted context omitted.

Typed languages can be better utilized for self documenting codebase. The types are used to show clear intent for the code.

There is a self-reinforcing network of assumptions in that statement: - Good architecture beats good code. - There are things I can express in dynamic languages which are hard to express in static languages. - If you're not expressing those things, typed static languages win. - When you're contorting your architecture to fit into static languages, dynamic ones win. - Of course, if you don't have experience with dynam…

Good enough code that works, at the right time, beats good architecture. Too many examples in computer science history.

Simple, clean code that works is the best way to express logical intent.

Eventually, everything compiles down to byte code. You can do it the easy way or the hard way.

Industry will use the most effective tool. Academics can experiment with high level concepts, but if it doesn't scale out, it won't be popular in the industry.