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

371–380 of 704 posts

Re: Software engineering topics I changed my mind on

#371

Post by tribaal »

Shorel wrote: post #248
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).

And I find a whiteboard a bit more intimidating. It kind of implies performing your writings in public. A notebook is a very personal thing. =)

I recently switched from a very whiteboard/paper heavy workflow to using a reMarkable tablet.

Holy shit this thing is good.

It's like an infinite notepad/whiteboard that auto syncs to the cloud, lets you define page layout templates, and renders PDFs and ebooks.

I've had it for just a few weeks and it's already the favorite pice of tech I own.

Re: Software engineering topics I changed my mind on

#372

Post by Falkon1313 »

christkv wrote: post #311
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…

We always run standups in the same way. What did I work on yesterday, what am I working on today and finally impediments or help required as well as general organizational stuff that might impact the team.

So do we, but generally a quick glance at the kanban board would show that for everyone. Well, it would if we had one unified board. Instead we have stuff scattered across multiple boards. Still it would only take 1-2 minutes to open them all up and glance through them. Information radiators. They work well.

Instead we have a 30-60 minute standup/sitdown/try-not-to-doze-off meeting to achieve the same thing. We used to also have additional meetings to review the boards but eventually cut those because people got tired of me saying "the status is still the same as I said an hour ago, because I've been in this meeting since then."

The exception is stuff like team announcements, reminders that someone's going to be out, requests for someone to volunteer to take a task. That can all be done async though.

Re: Software engineering topics I changed my mind on

#373

Post by Scea91 »

js8 wrote: post #368
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…

> 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 looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so t…

Reason why I don’t want my team to overspecialize:

I don’t want them to isolate and develop tunnel-vision. I want everyone to be aware of the project goals and understand the work that needs to be done to deliver value.

My experience with teams where people are divided by topics for a long time is that unpleasant work that does not fit into a single topic well gets neglected.

Re: Software engineering topics I changed my mind on

#374

Post by username90 »

rebeccaskinner wrote: post #294
thayne wrote: post #230

> Java isn't that terrible of a language True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.

This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer…

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 have namespacing.

Also that you need to have 100% super guaranteed unique global namespaces making your folder structure that horrible net.xxx.abc.adsasd.dfer.cthulu.NetXxxAbcAdsasdUtilityHelperBuilderFactory things, which for some reason wasn't needed in any other programming language and it worked just fine for them so you don't need that either.

With that instead of importing stuff you could just write something like, assuming each library have a sensible top level name:

    gzip.File g = gzip.File.FromDirectory(dir);
When I write Java personally it looks closer to that. And when I follow a corporate style I write it more like that, as close as possible while still following the style guide. I 100% believe Java could have been a nice experience if it didn't have its horrible over engineered style guides.

Re: Software engineering topics I changed my mind on

#375

Post by Jestar342 »

js8 wrote: post #368
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…

> 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 looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" I wonder why these "agile practices" shun the expertise so much. Instead of Y working on a similar problem as X in another month, why not make X an expert in the thing so t…

That's "Siloing" which is considered a negative pattern. If X is the expert, then only X can work on that something*. X is now a bottle neck.

Natural siloing happens, but you (team) should be striving to reduce it, not encourage it.

*More accurately: work can only proceed on that something when X is available*

Re: Software engineering topics I changed my mind on

#376

Post by arendtio »

ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

I believe, that many project managers are actually bad project managers. And that is not so much their fault as project managers are being trained on methods big time, but then again then job they have to do is not just executing these tools somehow, but to understand the dynamics in larger organizations and to act accordingly. But many project manager just learn the tools and methods to perfection and try to bring their cure to everyone by prioritizing method adoption, when many times the missing methods are not the most important problem.

So many times there are politics and emotions part of the broken communication that causes quite a lot of havoc these days. So instead of teaching developers how they have to work project managers should focus more on how to foster collaboration and use their people skills to reduce friction between people.

Having a good idea of exiting methods can be advantageous, but should never distract from the first priority to actually help the people who do the work, as good as they can.

Re: Software engineering topics I changed my mind on

#377

Post by bawolff »

Joeri wrote: post #332
bawolff wrote: post #26

Earlier quoted context omitted.

People always talk about nosql scaling better, but some of the largest websites on the internet are mysql based. I'm sure some people have problems where nosql is genuinely an appropriate solution, but i find it hard to believe that most people get anywhere near that level of scalability.

Those very large mysql deployments typically use it as a nosql system, with a sharded database spread over dozens or hundreds of instances, and referential integrity maintained by the business layer, not by the database. For a good example of a high volume site using a proper rdbms approach I would look at stackoverflow. It can (and has) run on a single ms sql server instance.

Even if that's so, still suggests rdbms are a good choice.

I do know for Wikipedia, english wikipedia is mostly a single master mysql db + slaves, with most of the sharding being on the site language level (article text contents stored elsewhere)

Re: Software engineering topics I changed my mind on

#378

Post by kyberias »

woutr_be wrote: post #271

> Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, t…

Unit test that documents the required functionality of code helps a lot. After that, one can refactor the code with all kinds of cleverness.

Re: Software engineering topics I changed my mind on

#379

Post by Falkon1313 »

busterarm wrote: post #199
ithrow wrote: post #194

Earlier quoted context omitted.

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 specifications. Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?

You've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.

Eh, not so much databases, but in terms of code, super flexible 'all things to all people' generic abstractions tend to be a lot more work and a lot more difficult to debug than a tight solution tailored to the problem it's solving, written in domain terminology.

If only I had a nickel for every hour I've spent debugging abstractions and indirection that were just there for the sake of adding flexibility that would never be needed.

Re: Software engineering topics I changed my mind on

#380

Post by avereveard »

H8crilA wrote: post #104
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…

It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.

I'm glad I've reinvented the wheel that many time as a junior, it let me learn why some framework and some solutions are the way they are, and made it extremely easy to pick up third party solutions later on
Post reply on HN