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

251–260 of 704 posts

Re: Software engineering topics I changed my mind on

#251

Post by mdtusz »

roganartu wrote: post #145
danfang wrote: post #113

I agree with most of the points the author makes. > Pencil and paper are the best programming tools and vastly under used I'm not convinced of this one. I grew up with digital tools only. Can someone give me examples where this assertion is true?

> I grew up with digital tools only. This implies that you exclusively use digital tools, so my first question would be: have you tried using pen and paper for things? It's really hard to give compelling examples of where pencil/pen and paper are going to be better than digital tools because everyone is different. If you want to try it out, I recommend simply keeping a pad and a pen at your desk and when you're stuck…

> My notebook is full of unorganised notes that I jotted down when a lightbulb came to me one day, rough sketches or mappings of solution ideas, brainstormed lists of features etc.

This is to me the biggest benefit of using pen and paper, but it requires shifting your attitude towards pen and paper to treat everything you write as disposable. Just freely sketching out ideas and using paper as a place to dump thoughts without concern for quality, formatting, or even having them be cohetent, is probably the most productive way for me to solve problems - so much so that I have switched to using large post-it notes, rather than a notebook. The good notes stick around for a few weeks, and the bad ones go straight into the bin.

Re: Software engineering topics I changed my mind on

#252

Post by BeetleB »

joseph_grobbles wrote: post #167
silentsea90 wrote: post #147

Earlier quoted context omitted.

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…

I've worked in three fortune 500 companies (banking and finance). Several SV tech companies (in satellite offices - not in SV). Two pure startups. An engineering firm. I have never seen it be anything but a waste of time. And it always consumes significantly more time than the boosters claim it does. And we can look at each other's anecdotes with suspicion. But there's a paradox that when someone says "Oh it's only 1…

You didn't address the very basic issue: Why can't your team(s) have proper meetings? People coming on time, or at least not waiting for people to come on time? Why can't they maintain the discipline of not ratholing and going off into technical issues?

As I'm not necessarily in favor of standups, nor has anyone responding to you claimed to be, you're simply blowing hot air complaining about the purpose behind standups as opposed to addressing the comments they are making.

Not respecting people's time (frequently late for a meeting, meeting organizers making the on-time people wait for the off-time ones, etc), not being able to communicate well (cannot summarize, or meanders to off topic stuff) are all qualities of poor workers and poor teams. Such behavior is quite common, in my experience, but these are legitimate reasons not to work with them. Once you hit some minimal level of technical ability, the other skills matter at least as much in a team environment.

There are plenty of pointless rituals most people have to do in their life and work. Amongst those things, being able to handle a simple 15 minute meeting a day is one of the easiest. When people have trouble with it, it's a sign of a behavioral problem. Either some team members do not have the minimum bar of discipline/communication, or they are intentionally acting this way as some sort of civil disobedience against scrum. There are usually appropriate ways to make change - in most cases such behavior is just a sign of immaturity. Of course, there is such a thing as poor management, and sometimes such behavior is the only realistic way. But then again - it's still a good turn off for me not to work there.

As I said in another comment: Following scrum does a good job of exposing problems. And everything you describe sounds like problems in the team or the management.

Re: Software engineering topics I changed my mind on

#253

Post by jackfoxy »

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus.

The OP has intuitively gravitated to this side.

Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful, but should never be regarded as having special significance.

And in this regard, don't micro-services fly in the face of Occam's Razor? Or as the OP stated

Monoliths are pretty good in most circumstances

Re: Software engineering topics I changed my mind on

#254

Post by pseudalopex »

ncann wrote: post #201
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…

While you have a point, it's not that rare for someone to be blocked on a hard issue for a day or two, even having talked to someone, then bring that up at the stand-up. The one you talk to may not always have the solution, and it may be someone else in the team at large.

Email works great for that.

Re: Software engineering topics I changed my mind on

#255

Post by xxs »

busterarm wrote: post #188
specialist wrote: post #171

Earlier quoted context omitted.

I was on a team which used DynamoDB for their hottest data set. Which would trivially fit in RAM.

If I had a dollar for every senior engineer I've worked with who has never heard of SQLite...

Truth be told I am yet to see a reason to use in-memory database. Datstructures, maps/trees/set - yes. Concurrent/lock free/skip lists/whatever - all great. I don't need a relational database when I can use objects/structs/etc.

Re: Software engineering topics I changed my mind on

#256

Post by bear8642 »

tcbasche wrote: post #174

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.

>test first it wouldn't have been half as dodgy.

Feel part of this, in my very little experience, is with tests focus is getting smallest thing working so less to go wrong

Re: Software engineering topics I changed my mind on

#257

Post by Shorel »

busterarm wrote: post #183
PragmaticPulp wrote: post #41

Earlier quoted context omitted.

As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specific…

There are only two options for me: MySQL or Postgres.

And using AWS generally means using Aurora. Then the choice is already made. Not hard at all.

Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.

Re: Software engineering topics I changed my mind on

#258

Post by trentnix »

90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.

Manager and sometimes dev lead here. I agree with this, but would qualify that it’s not because teams are “self-organizing” or self managing or whatever claptrap the consultant sells. A good manager - or better said, a good leader - can make a massive positive impact on the efficiency and quality delivered by a team.

There is a massive absence of good leadership in the software industry. All manner of process and certifications and other bureaucratic scaffolding have been invented to try and work around the absence of leadership, to little avail.

Make no mistake, those practices and processes and certifications can help good managers become better. But they don’t turn bad managers into good managers and don’t compensate for an absence of leadership.

Re: Software engineering topics I changed my mind on

#259

Post by pseudalopex »

joseph_grobbles wrote: post #138
BeetleB wrote: post #116

Earlier quoted context omitted.

In the one job where standups went well, our limit was 15 minutes, for about 7 developers. > Standups are initially scheduled for the start of the development day. There's no reason it should. We did not have it at that time. If it's at a reasonable time (e.g. after all people have normally begun work), then have a low tolerance policy for those who come late. Sometimes our standups were about 5 minutes, because some…

If you don't have it at the beginning of the day, then you're putting a hard gate on flow. This phenomena is well known, and the disruption of having a scheduled event mid-workday is significantly larger than the time of the disruption. Everyone is going to fade out of their work long before and won't re-engage for sometimes after. As to scrum exposing cultural problems, maybe that's true, but in some cases scrums ar…

Talking about the beginning of the day assumes everyone starts at the same time. Having it just before most people go to lunch can be less disruptive. I agree scrum isn't helpful usually though.

Re: Software engineering topics I changed my mind on

#260

Post by jdlshore »

loosescrews wrote: post #143

Test driven development requires you to have a spec upfront. When you already have a testable spec, test driven development seems to be a net positive. It can be a good way to explore the spec before building the implementation. At the same time, you shouldn't force yourself to write all of the tests up front; additional tests will typically occur to you as you build the implementation. If you don't have external fac…

> Test driven development requires you to have a spec upfront.

What? TDD was created by Kent Beck as part of XP, which is about as far from up-front design and spec as you can get.

Post reply on HN