Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

81–90 of 704 posts

Re: Software engineering topics I changed my mind on

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

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed.

If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in a large org that pushes those menial tasks onto engineers. PMs are there to facilitate engineers. They do not rule over them. They make targeted, efficient queries of engineers' status and then communicate and coordinate appropriately.

I would love to see PMs hired at my org. We're currently drowning in process-related tasks and it's mostly because we do not have PMs(the process is mostly necessary, but wastes engineer time). I'd also love to have some technical writers on staff. Having engineers write documentation, beyond, say, doxygen comments in header files, is just dumb. Right now our user facing docs have little consistency or defined scope. They don't target a well defined audience, and don't effectively communicate to our users.

Let engineers do what they do best, and enable them to be productive by hiring helpers as needed.

Re: Software engineering topics I changed my mind on

#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 looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!"

Seniority has nothing to do with this. Communication/coordination/knowledge-sharing matter at all levels.

Re: Software engineering topics I changed my mind on

#83
post #66

11 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.

You can do the bare minimum with a path to scale, though. But it seems like when things 'scale' a lot of changes are required regardless, so I feel like it's a bit of a moot point.

Plus, 'scalable' can refer to the codes performance or the codes malleability, and the two are often conflated in blog posts :P

Re: Software engineering topics I changed my mind on

#84

The author of this seems like a real joy to work with > “TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.” Imagine thinking about colleagues as people with “frail little minds.” Yikes. Many of the other points betray serious attitude and perspective problems, but it was forgivable until getting to that last bullet and realizing, no, this is just a person wit…

>Imagine thinking about colleagues as people with “frail little minds.” Yikes.

He's not thinking about ALL colleagues, but "TDD purists".

And even so, it's obviously a turn of phrase to dismiss the hardcore purism, not something the author generally feels about such people in their entirety.

Re: Software engineering topics I changed my mind on

#86
post #66

11 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.

You can hedge by breaking up your codebase into logical services from the start which own their data sources and controllers. When the time comes to break up into microservices, you separate each service into its own application rather than grouping them in a monolith.

Re: Software engineering topics I changed my mind on

#88
post #69

Coming up on 30 years. I agree with most of your observations except standups. In my experience daily standups are a waste of time. Maybe I've just had bad luck with them?

The problems creep in if they get too big. Too many people and it's a huge waste of time. If non devs are sneaking in, they shouldn't be permitted to speak.

I love stand ups but agree they need to stay small. When the audience is too large it becomes an exercise in bragging and is not functional.

Re: Software engineering topics I changed my mind on

#89

I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.

I think some people just have better or worse tolerances to these things than others.

If formatting in code is as I am used to it, I can skim it very quickly. If it is not, I have to focus much more, and that adds up over the course of a day.

My brain can just recognize what's happening in a small block of code if it has a particular shape and colors. I don't know how to explain it better than that.

This is one reason I REALLY want to see editors save files as tokens rather than plain text, and see compilers ingest code as pre-parsed tokens rather than plain text. (Or have editors save the tokenized file alongside a plain text file for the compiler.)

If that ever happens, I will be able to view the code exactly as I like it, and so will everyone else, even when we each want to view it differently.

Compilers and diffing tools will need to report a token number rather than a line number for errors and differences, and I don't see that as a big problem at all.

Re: Software engineering topics I changed my mind on

#90
post #42
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.

Exactly, and from a features standpoint Postgres can do everything Dynamo can do and so much more . I think a lot of software devs don't really know SQL or how RDBMS work so they don't know what they are giving up.

This is similar to how I feel about graph databases. Twitter (FlockDB) and Facebook (TAO) built scalable graph abstractions over SQL without a hitch.

Why would I want to use a graph DB directly then?

Post reply on HN