Person5478

I actually wonder if it's due to being a software developer.

Over time I've come to realize I'm a software developer who hates software. I love the process of developing software, it's a creative outlet for me, but more often than not software written by others gets in my way. It's a distraction from me being able to solve the problems I actually care about.

It's one of the reasons I still use vim for programming, I've never had it go belly up on me in the middle of editing, or be slow.

And maybe the more experienced developers have, over time, developed a better sense of what's important and what's not.

> This is why we need to program defensively.

I agree wholeheartedly and I wish more developers felt this way.

I hate opening new projects and seeing the potential for null reference exceptions everywhere when you could instead just check the constraints directly and give a more meaningful response.

> This has been a big thing on my mind recently because I've been asked to do a design review for a system created by some high-SLOC-productivity people who built a complex system with a sophisticated-looking architecture but who keep giving me answers like the second one.

I've recently found myself in the middle of one such team, except without the high productivity part. Sometimes I think I'm the only sane person in a sea of mad, and at other times I wonder if maybe I'm just dumber than I think and don't understand.

I've designed and built systems that get deployed around the world, but if you look at my code and architectures, they're relatively unsophisticated. I just don't see the need for sophistication unless it's solving a specific problem, and I find these highly sophisticated designs just make everything harder (for me anyway).

In practice code review allows 1 or 2 people on the team to insist on their preferences throughout the project.

I once saw a 3-4 line fix turn into a rewrite of an entire page that took several full-time days to finish because the developer didn't like the original fix. I've seen a former DBA turned software dev insist on using nulls throughout the codebase rather than empty strings and ignore the argument that's not considered good practice as a software developer because they themselves are "now software developers".

And the rebuttal is always the same, "well you're just doing it wrong". Maybe, but it gets done wrong more often than right.

I'm not against code review per se, but the number of times I've seen silly and arbitrary changes because of one developer's sensibilities is way too high.

This is probably my biggest beef with the "culture" of software development nowadays.

Back in my day (hold on while I go grab my cane...) software developers would just flap their lips and sound would come out at each other.

Nowadays there seems to be this underlying assumption that actually talking to each other is a waste of time, that it should all be documented with no curation, and should always be in PR's, et al.

I'm all for documenting decisions, but I feel like it's not too much effort to swing by someone's office and have a discussion with them. At that point, maybe you don't even need to document if the updates are small issues. Is it really so all-encompassingly important?

But maybe I'm just old. Most of the time I'd rather talk to a human when I call into tech support too (unless it's something obviously automated like making a payment).

I understand and agree with your point, but I think the word enriched is too ambiguous here. He definitely enriched the software industry, just not monetarily.

yeah, and that idea is so obvious it's a little difficult for me to understand why the original comparison was even made.

> The Clintons earned over $150 in speaking fees

Man, a whole 150 dollars, those Clintons must be making bank! :P

we as a society will move on from it at some point. It's not really about winning the cultural war, it's about the elites manipulating the population and thus using the language du jour.

20-30 years ago it would have been about family values, christian values, and down with the gays. In 20-30 years it'll be something else, but what won't change is those in power stay in power.

seriously. What next, Jeff Bezos can throw around 100 million without being accused of corruption because it's such a % of his overall worth?

I can't even think of a way that attitude makes sense.

yeah, that was my thought too.

I can literally pay for a $5 VPS and get off the ground in mere weeks as well. The only thing I don't get is the potential performance of AWS, but you have to pay extra for that at AWS as well, so paying extra outside of AWS for it isn't outlandish.

Now, AWS has a lot of value addons that can make it worth it/useful, so perhaps there's a point there but it's not nearly as noteworthy as the other poster is making it seem.

My biggest complaint wrt their prime video player is that the subtitles will, over time, slowly desync more and more with the audio.

Having said that, one of the reasons why I'm a huge Amazon fan is because they have such great service. For example, I purchased a PS4 that died 3 days in and it was the easiest thing in the world to get it sent back and replaced.

It's one of the reasons I generally trust ordering expensive items through Amazon.

I feel the same. I've fallen behind in terms of the episodes being released and don't feel any particular need to catch up.

I'll watch them eventually, but it's just not exciting enough for me to make it a priority.

From my perspective, that back and forth is a natural part of software development. If they wanted red and once they see it they decide they want a different shade, to me that's good software development (as long as it doesn't turn into bikeshedding).

Often people aren't sure themselves what they want until they see it, or they get new/better ideas after seeing it in motion (or decide they don't like it). Good software dev is like boiling water. It's tumultuous with a smattering of chaos, but in general drives towards the goal.

It also allows you, as a developer, to take more ownership of the software as a solution. At the end of the day you're helping solve someone's problems. For me that's satisfying, even if it's a small problem.

And it's been my experience when you do that well, people love you for it.

And to be clear, I put customer in quotes for a reason. Sometimes the problem you're solving is that batch job needs to be realtime, or that one query is slow as the data got too large, ad nauseum. It's not always non-technical people.

What I never want is a PM to just tell me to make a query faster without being able to discuss with the people it affects what their use case is so I can start optimizing for the specifics rather than just in general (although sometimes that's the right approach).

That's so foreign to me I just have to ask why.

My experience is that people rationalize what they want. If they want microservices then you're going to get microservices.

It's not all nefarious, I think if many of them truly _UNDERSTOOD_ the difficulties of microservices it would give them pause (there's a difference between knowing and understanding), but they want what they want, they're optimistic, and they tend to back into the reasoning afterwards.

I have an analogy I like to use.

No one in their right mind would put an engineer on a factory line because said engineer built the machine. Yet people are completely ok handing off tasks to developers and asking them to do the mechanical part of the job.

In both cases you're only extracting half the value from that person that you could be.

That back and forth with your PM isn't wasted time, it's you digging in to better understand, and in doing so are given the opportunity to identify and make suggestions due to the expertise you have that the PM doesn't. I'll go one further. Your company should endeavor to put you face to face with the "customer" making the request if it's practically possible for exactly the same reason, and your PM shouldn't be involved at all outside of setting the priority for the work itself. This is of course ideal circumstances and there are always reasons why the reality can't match exactly, but in general this is what you should be endeavoring to do.

The biggest issue I've seen with Indian workers is they want to be handed everything so they can be left to the mechanical aspect of typing in code.

The first time you come across this it's a bit of a culture shock as I think most in the US are more used to having a back and forth exchange.

As companies grow there will be "pain points" that come up due to scaling (performance, architecture, development, etc). When you get to that point it's normal to wish the pain didn't exist by "doing it right" the first time, but I think it's still better to wait until you have the pain. Because that pain tells you unequivocally what you need to value in the scaling.

I agree with him. It's indicative of more idealism than practical sense, which is indicative of inexperience.

As a 20+ year vet, what worries me is when someone starts talking in terms of good or bad.

It's a spectrum, not a binary. There is code that's just egregiously bad. There's code that's just egregiously good (and it's not clear which is more expensive to produce and maintain). But the vast majority falls into the grey area in between those extremes.

The other poster (koonsolo) has just seen enough different codebases to have come to the conclusion that it's not nearly the most important aspect of a projects success. And I agree with them on that point (wholeheartedly in fact).

Developers concentrate on it because it's what they're in all day, the same way that a DBA is going to concentrate on the data model because that's where they're at all day.

But in the grand scheme of things, developers way overblow the value of great code. I also have reservations about the claim that most developers even know what great code _LOOKS_ like, I've seen too many terrible codebases that were claimed to be well designed by their creators.

My point is that if the code isn't actively causing you problems then leave it be, and stop calling it good or bad. Call it what it is, working code that doesn't need to be bikeshedded over.

I made myself clear in my initial response:

> Webforms was their attempt to bring the VB6 workflow onto the web and it was a terrible idea specifically because the web is not desktop.

As for performance, viewstate was a huge performance issue. That's a large part about what I meant when I said they tried to bring the VB6 workflow onto the web. In order to get there, they had to create the viewstate mechanisms, which created a different set of problems.

They wanted developers to be able to dragNdrop and then double click and write a small bit of code to do a thing, just like in VB6. Only, in order to actually get that to work, they had to come up with things that were actively harmful in a website (and it got worse when they tried to shoehorn ajax into it).

> There is nothing to be learned from your posts at all, no different perspective, no justification of your opinion, no insights into why you dislike it. You're just doubling down on a preconception that you have no justification for.

this is just an HN dog whistle. You could have asked.

I never said it was a moderation failure, as I said it was politely given.

And I'm not providing links because I don't have them, these are things I've noted over the years as a lurker. There's so much back patting about the moderation on this site that I'm often miffed that no one sees the negative consequences. No system or approach is perfect, and the approach you guys take on this site has its share of downsides as well.

I once saw a person on this site argue all safety regulations should be gotten rid of and let the market decide the cost. The theory is that as more accidents happen the insurance will rise and that will self-correct by causing companies to enforce their own internal safety requirements.

The implication being it's ok for Bob to live the rest of his life without a leg because the company was willing to pay the insurance premium. That Bob's quality of life shouldn't factor into the equation.

The problem is that when someone has an opinion like this, they cannot be put down as strongly as they should. "In real life" if someone walks into a public space and announces they believe a 30 year old should be able to enter into a sexual relationship with a 10 year old, not only would there be a reaction, there would be a __very strong reaction__, and the strength of that reaction is a part of the policing we do amongst ourselves as a society.

But because of the values this site has, if someone were to express that opinion on these boards, the people getting banned would be the ones reacting strongly.

And _THAT_ is why I agreed with the other poster that you do, in fact, moderate based upon HOW someone says something while pointing out that it has its downsides.

You said the following:

> it had much better benchmarks than interpreted languages at the time

That seems an odd statement for someone not confusing WebForms with the tech stack.

You can build applications in asp.net framework without the use of WebForms (and you could do so before MVC existed). THAT tech stack was pretty reasonable. It was WebForms specifically that was the problem.

> As far as I can tell, HN mods focus more on how you say something rather than what you say.

This is true and I've seen some extremely vile, reprehensible things said, but that went unmoderated because they were said politely (I've actually seen people responding to these vile things get banned because they weren't nearly that polite).

Until Google does something else I'd give them a pass. Steam, for example, will give you more information about the reviews to avoid brigading.

I'm more inclined to believe Google is trying to head brigading off. When they start being more active however ... then we can no longer give them the benefit of the doubt.

But I'm 100% with you wrt Discord/FB.

> With that out of the way, I would recommend using a test double in exactly one kind of situation: When it's genuinely awkward to use the real thing.

THANK YOU.

I'm actually pretty staunchly anti-mocking (and anything similar). I think too many developers start thinking of testing as the goal rather than as the means. What this means to me is I don't care if it's technically an integration test vs a unit test, I care that it tests _REALITY_.

There are times when the isolation given by mocking can be useful, but I submit it's useful far far less often than many claim. And your examples are a good use as well.

But imo trying to mock everything is mostly mental masturbation only with long-term maintenance costs.

You're confusing webforms with the asp.net framework.

The framework itself was mostly good tech, as long as you didn't use webforms.

Probably the biggest flaw in the framework was not having a way to capture all unhandled exceptions (Application_Error does not catch unhandled asmx exceptions).

... and WebForms.

I've never seen anyone actually say MS got it RIGHT with webforms.

Webforms was their attempt to bring the VB6 workflow onto the web and it was a terrible idea specifically because the web is not desktop.

I get your point, but as far as I'm concerned any rationale that ends with the conclusion that MS got it right with webforms needs to be seriously reconsidered.