Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

261–270 of 704 posts

Re: Software engineering topics I changed my mind on

#261
post #251

Earlier quoted context omitted.

> 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…

>rather than a notebook

Enjoyed these notepads (http://www.computinghistory.org.uk/det/46261/Floppy-Disk-Not...) for quick scribbles.

More substantial then post-its yet pages easy pull out

Re: Software engineering topics I changed my mind on

#262

It's good list. Except the TDD rant. TDD can be reframed as codified specifications with test verifications. Then, the TDD purists do have a point.

Then it’s not (edit: pure) TDD. The TDD purists I’m familiar with think if you write any code before you write the tests, you’re doing it wrong.

That’s a common misunderstanding of TDD, but it’s incorrect. TDD is an incremental cycle of write test, write code, refactor, repeat. Typically less than 5 lines at a time.

Re: Software engineering topics I changed my mind on

#263
> Typed languages are better when you're working on a team of people with various experience levels.

Even if you are working alone you should probably treat it as working with people with various experience levels if it is code that you are going to have to periodically deal with in the future.

When older you has to come back to the code, older you should be more experienced that younger you in general, but older you will also likely have forgotten much of what younger you was thinking when younger you wrote the code. In effect, older you and younger you are a team with various levels of experience.

Re: Software engineering topics I changed my mind on

#265
post #194

Earlier quoted context omitted.

> 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…

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?

[deleted]

Re: Software engineering topics I changed my mind on

#266

Earlier quoted context omitted.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

Someone told me once it's more important to design things to scale 1 or 2 orders of magnitude and be easily replaced. What you think you'll need 2 or 3 orders of magnitude from now is rarely what you need when you get there.

Yes, but it's also easy to get bogged down reimplementing, right when you have more important things to focus on to keep up with growth. Designing things to be easily replaced is easier said than done.

Re: Software engineering topics I changed my mind on

#267

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…

Agree with this wholeheartedly. Standups are annoying but I have learned they are necessary, even as a very experienced developer. Sometimes things just cone up you wouldn’t otherwise know about and it encourages helpful, meaningful communication amongst the team. What’s not helpful is when standups are treated like status reports. That’s not the purpose - even uber green newbies are responsible enough to do their wo…

> not helpful is when standups are treated like status reports

> simply state what you’re doing

Honest question, what's the difference.

Re: Software engineering topics I changed my mind on

#268
post #263

> Typed languages are better when you're working on a team of people with various experience levels. Even if you are working alone you should probably treat it as working with people with various experience levels if it is code that you are going to have to periodically deal with in the future. When older you has to come back to the code, older you should be more experienced that younger you in general, but older you…

Older me is continually pissed off when I encounter something clever that younger me did. I've tried to be less clever over time.

Re: Software engineering topics I changed my mind on

#269

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.

We decided early on that a daily scrum was just too frequent to be effective for our team, so went to 2x per week. When we started working from home, we added a "keep in touch" meeting for the other 3 days of the week just to stay connected.

Re: Software engineering topics I changed my mind on

#270

Earlier quoted context omitted.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

If you build for millions of users the way most devs do, your business will flounder before you finish. Facebook, Twitter, and Google all started simple and scaled only when it became necessary. If you want to do what they're doing, start by doing what they did. Don't skip to the microservices.

We don't actually disagree, but I believe Twitter is actually one of the cautionary tales. Their product went through a long period of stagnation because they were too busy toiling at scaling. Same thing seemed to happen to Github, from my perspective.
Post reply on HN