81–90 of 247 posts
This is bad advice. It's like saying "go into a bar and start picking up fights".
If some part of the software has problems, runs slow or has bugs but nobody is complaining, then there's no problem. Why waste time improving it?
Almost 100% of the time when you solve a problem you just create new problems of different kind in turn.
Be lazy. The less code you write the better off you are.
Earlier quoted context omitted.
Only for certain strained definitions of "effective". And, if you are on the wrong side, it is very "effective" at ruining your life. Most of us would take a bit less "effective" in order to avoid that, thanks.
I don't understand the point of replying like this. Clearly we agree that the Singaporean government is very good at getting things done, and we agree that the things it wants to get done are horrible. Why are you speaking as if our opinions differ? Why manufacture conflict where none exists? Is calling something a quasi-Orwellian dystopia now too subtle an expression of disapproval?
"The tool is squeaky but it gets the job done" - you wouldn't expect the speaker to do anything about the squeaks. Squeaking is tolerable.
"The tool does the job but it's squeaky" - you would expect the speaker to do something about the squeaks. Doing the job isn't good enough.
Your comment is most easily read as not disapproving of authoritarian government when it is effective.
Earlier quoted context omitted.
It's not that they have the knowledge but that the knowledge is now encoded in software and available to anyone else - software shares knowledge without the users having to learn it (for example having to learn which five systems need to have their names enters in order to pay their parking fine
This is not what I have experienced, at least not in real world software with mediocre documentation. Usually the software encodes only the "how", but the important parts are "why" and what aspects of the original problem led to that design. Good teams learn how to transfer and adapt in the next project. Starting with the software only, lots of that can only be reverse engineered.
I thought "what a bold title, if someone's figured it out we can just close HN" and upon reading, hey it's not far off. The following is a wonderful point I have hardly ever heard said directly: "The main value in software is not the code produced, but the knowledge accumulated by the people who produced it."
weird, I've heard it said frequently for decades in various forms, "value your knowledge workers" "your employees are your most valuable asset" Some companies don't treat employees well, and some employees at good companies feel they are not treated well enough If the above quotes do not strike a chord with you, you might just be a software engineer who thinks you're more important than non-SEs.
...While I do agree that "project-management" is important, I think the tools we are using today are really underpowered to deal with complexity/human-error - Which is the bigger problem IMO.
Except for the 10x myth a fairly good article.
I disagree with that, if you describe it as stated in the article: "Overall, good engineers are so much more effective not because they produce a lot more code, but because the decisions they make save you from work you did not know could be avoided." I've seen plenty of poor decisions that cause 10x the work, and end up with something 10x less maintainable.
This is great. So many quotable quotes. If only we could make it required reading for our clients! This one struck me, because as soon as I read it I knew it was true yet had never considered it: > Most people only give feedback once. If you start by launching to a large audience, everyone will give you the same obvious feedback and you’ll have nowhere to go from there. I've been on both sides of that fence and it ri…
Earlier quoted context omitted.
You should consider making this it's own article. "...the designers job is not to pass along "the design" but to pass along "the theories" driving the design. Knowledge of the theory is tacit in owning..." Well said. Thank you!
I would prefer people read the original paper than any second-hand explanation of it. The paper is very readabale and understandable, and is probably relevant as long as into the future as human beings write code.
Earlier quoted context omitted.
> "Software Is about Developing Knowledge More than Writing Code" The company I work for uses Scrum. They consider the User Stories + the code to be everything you need. I struggle with this, but my manager says they don't want to get tied up doing documentation "because it goes out of date". Beside, they are being Agile which "prefers working code over comprehensive documentation". I am wondering what other companie…
prefers working code over comprehensive documentation This is funny because “working code” might just mean that it doesn’t crash. But does it actually do what it’s supposed to do or does it reliably deliver the wrong results? How would you know without documentation? The software in the Therac didn’t crash, it quite reliably killed people with its “working code”.
So I think "working code/application/program" is when it does what it is supposed to do. Including not crashing.