21–30 of 114 posts
Earlier quoted context omitted.
Is that unique to software though? Plenty of people can follow a plan but still find it tough to start from first principles, I would think.
I've worked for a bit in an engineering company and I was surprised at how bad they were at versioning their documents.
I can definitely write a 1KLOC program to solve a 10-line problem.
>(When I talk about a program that is so many lines long, I mean a program that needs to be about that long. It’s no achievement to write 1,000 lines of code for a problem that would be reasonable to solve in 10.)
Earlier quoted context omitted.
I've worked for a bit in an engineering company and I was surprised at how bad they were at versioning their documents.
Do you have any examples of correctly versioned documents?
I’m working on a history project at the moment which has reconstructed the version history of the US constitution based on the secretarial records and various commentaries written during the drafting process. At the moment we’re working on some US state constitutions, the Indian constitution, Irish peace process and the Australian constitutional process. We only have so many historical records of the committee processes, but it turns out to be more than enough to reconstruct the version history of the text.
I'd prefer maintainable programs of any size. Other than non-trivial academic samples, the odds of a program needing to change over its lifetime or large, and it's current apparent correctness has little to do with someone else adapting it to the ever changing environment. The number of times I've heard "it seems to work and we don't dare change it" is far too many
Some people take that as being scared, but it's more like "you have to have made this work and tested it before putting it in."
Then periodically there is a discussion on Hacker News that boils down to "all of the other engineering disciplines can make reliable predictions and deadlines; why can't software?" or "why is this company's code so shoddy?" or "why are we drowning in technical debt?".
Perhaps the these are all related?
When I was a prof (many years ago), I was working on a database for a political campaign. The code was a mess. I asked a couple of my colleagues (successful comp. sci. profs) to help out. It became clear very quickly that there are two kinds of comp. sci. profs: those who can program and those who cannot.
One of my computer science professors when his laptop wasn't connecting to the projector: "I hate computers."
It seems to me that in other areas of tech, companies generally hire electrical engineers, mechanical engineers, civil engineers, etc. On the other hand, software companies feel that they don't need to hire computer scientists. Then periodically there is a discussion on Hacker News that boils down to "all of the other engineering disciplines can make reliable predictions and deadlines; why can't software?" or "why is…
To me, a computer scientist is someone who studies computation. They probably have the skills to figure out the run times of algorithms, and probably develop algorithms for solving arbitrary problems.
A software engineer is what I would call someone who can estimate and deliver a large software application fit for purpose.
Earlier quoted context omitted.
One of my computer science professors when his laptop wasn't connecting to the projector: "I hate computers."
That's one of the ones who could program.
It seems to me that in other areas of tech, companies generally hire electrical engineers, mechanical engineers, civil engineers, etc. On the other hand, software companies feel that they don't need to hire computer scientists. Then periodically there is a discussion on Hacker News that boils down to "all of the other engineering disciplines can make reliable predictions and deadlines; why can't software?" or "why is…
Is your working definition of a computer scientist similar to a civil or electrical engineer? To me, a computer scientist is someone who studies computation. They probably have the skills to figure out the run times of algorithms, and probably develop algorithms for solving arbitrary problems. A software engineer is what I would call someone who can estimate and deliver a large software application fit for purpose.
CS programs have gotten better at teaching real SWE skills, but the median CS grad still has ~zero real SWE experience.
> how to organize software so that the complexity remains manageable as the size increases So John is missing the role of software architect here. Science, art, and development - 3 roles. Not all visits to the stratosphere are misadventures.
I frankly don't believe in the "software architect" as a separate role. I've worked with "architects" who are clearly just BS artists because they know the jargon but have no skill to back it up and make difficult technical decisions regarding tradeoffs.