Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

661–670 of 704 posts

Re: Software engineering topics I changed my mind on

#661
post #392

Earlier quoted context omitted.

Did you know that Java lets you any number of module scoped classes in a single file, just that the public class has to have the same name as the file? There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. Its just that the eco system standards were set by people who thought that having unique class names were super important even though Java already h…

> There are a lot of things like that you can do in Java which people just don't do that makes many things a lot cleaner. The problem is not "people could use that particular Java feature to make code cleaner, but they don't". The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out wh…

> The problem is on a higher-level: If you have ever tried to read your way through some library, e.g. Spring, you'll see code spread over hundreds of files, and it takes ages to just find out where that particular bit of code you need is, because it's automatically injected in some builder class which is an inner object extending some other object that implements an interface somewhere.

There is nothing about Java the language which forces code to be written this way though.

Re: Software engineering topics I changed my mind on

#662

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…

> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. My score is similar, and kind of agree. The eerie part is that the intuition can discern a good hire within 2 minutes with fairly high probability, and within 10 minutes with near certainty. The rest of the interview process is just padding to figure out whether the intuition is not wrong (it…

No, they do not. Or at the very least you should not draw conclusions like that. How do you corelate language skills with technical abilities? There is large group of people who even with perfect language skills is unable to shake off the accent as it is probably genetics/biology. Thats why you hear accent in "foreign" people after 20+ years.

Please, trust your intuitions little less. Treat more of your impressions as anecdotal :)

Re: Software engineering topics I changed my mind on

#663
post #647

Earlier quoted context omitted.

Not having a formal cs background, the comments on HN that wax about predicate calculus and algebras always raise questions for me. Is it a higher plane of programmer thinking or just abstract technical jargon and ideas that are suited for hard core technical cs research but bear little value in practical programming tasks? Like knowing the Latin names and full phylogenic tree and exact relation of humans to the anim…

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?

Re: Software engineering topics I changed my mind on

#664

Earlier quoted context omitted.

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.

What about the fact that some stuff just takes time, is that not conceivable to you ?

Stand up is not (supposed to be) oppositional/conflict driven (but there are many toxic workplace cultures). Obviously some things "just take time", but what is the stuff that's taking up time? Assume it's all developers in the room and we're all familiar with the code base. Are you doing a stupid boring refactor of a thing tat "just takes time" but someone on the team wrote - and they have thoughts on pitfalls to avoid if they were rewriting it? Are you banging your head against an elusive bug that "will just take time" to tease out? The point of the standup is to shine light on any number of stupid pitfalls that every developer, even (especially) seasoned developers get stuck on, have dealt with in the past, and can give guidance with.

If you're just cargo-culting having a daily 15-minute meeting under the guise of agile or whatever, and it's just a status meeting, then cancel it, until after people learn to have a proper stand-up. Waking up just to go to a meeting and report "I'm still working on the thing", is a waste of everyone's time, and is a meeting that would have been better off as an email. (Provided people can send that email, which is not always possible, and is an entirely different topic.)

Re: Software engineering topics I changed my mind on

#666

Earlier quoted context omitted.

We'll never know the counterfactual, but in my opinion: You could have learned the same thing more efficiently, with more support for why you didn't need to reinvent the wheel.

I've been a professional software developer for ten years, and I'm on a hiatus right now. One thing I've been doing with my time is reinvent a bunch of wheels, implementing broken clones of this library or that algorithm, and I've gained a tremendous amount of understanding of what's going on behind the scenes of tools I'd been using for years. So yeah, it's a valuable learning tool to build with your own hands. Also…

Before getting sucked into the enterprise world, I reinvented a bunch of wheels and this indeed gave me a deeper understanding of the inner workings of various frameworks and technologies. I noticed that my colleagues who had ten years or more on their resume rarely had any idea what I was rambling on about or the basis for the things they were using.

Their were so busy trying to get stuff done that they never had time to explore. I don't mean blog post or tutorial explore, I mean weeks and weeks of implementation and testing of patterns and low level engineering. Building database engines from scratch or writing a compiler or a distributed message broker, for instance.

Re: Software engineering topics I changed my mind on

#667

Earlier quoted context omitted.

> often in the form of production outages Completely unrelated. If you have production outages resulting from new code you have serious gaps in your certification process, especially so if the new code covers existing process/requirements. You are probably insecurely reliant upon dependencies to fill gaps you haven’t bothered to investigate, which is extremely fragile. The benefit of code reuse is simplification. If…

> If you have production outages resulting from new code you have serious gaps in your certification process If you have production outages every week, yeah. But no organization is free of production outages. When they do happen (I said when, not if) it matters a lot if you used standard libraries, code that is plugged into the infrastructure, and the like, and not hand-rolled cowboy code

> it matters a lot if you used standard libraries

Why? From a security perspective, an outage is a security matter, the remediation plan is what’s important.

Re: Software engineering topics I changed my mind on

#668
post #204

Earlier quoted context omitted.

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.

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).

Don't write on the lines, and draw pictures.

Re: Software engineering topics I changed my mind on

#669

The TDD one I sort of half agree with. Purism and zealoutry are rarely a good reaction to anything, but I've seen a lot of dodgy code that, if it had been written with at least testability in mind, or with a test first it wouldn't have been half as dodgy.

I tend to do TDD because I hate having to pull up a full application, run the thing and then eyeball a result. The problem with TDD zealotry is that often they'll induce all sorts of architectural rot (DHH did a thing on test induced design damage a while back) in the name of testability

Re: Software engineering topics I changed my mind on

#670

Earlier quoted context omitted.

"10 minutes" Are you the only one attending or something? Standups are initially scheduled for the start of the development day. But then people come in a little late, get that first minute call, have to attend to something that hiccupped, so soon enough the standup happens 30 minutes into the day, eventually an hour into the day. So if you did get there on time, now you just spin your wheel waiting, because first yo…

I am not sure where you work, but I am surprised that with such a lackadaisical attitude towards attending a meeting, any work gets done at all. If you have a meeting at 11 AM in the morning, people are supposed to show up on time. Do all your meetings run late? Or does only the standup get this treatment? Sidenote: if somebody's late > 2 mins, they can join midway or miss the standup altogether, just as is the case…

We had fines for latecomers and people that talked too much at one of my last companies, like $2 or whatever that goes towards end of week beers or the Christmas party. People pulled into shape real quick.
Post reply on HN