Does the software industry learn?
tomrenner.com
Does the software industry learn?
1–10 of 102 posts
Re: Does the software industry learn?
#2I would also like to read a well-written analysis of COBOL, what it did right and what it did wrong.
A problem the article doesn't mention, is that the percentage of still-programming developers who are young (<30 years) is higher than in other professions, for several reasons, so the lessons learned 15 years ago are often lost.
Re: Does the software industry learn?
#3Nope.
Re: Does the software industry learn?
#4Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
Re: Does the software industry learn?
#5Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
Hardly specific to software engineering, and maybe (but not certainly) that should tell us that there is something to navel-gazing and reworking of fundamentals and basics.
Re: Does the software industry learn?
#6Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
Lookup YouTube on how many people built a chair, desk, or any other basic piece of furniture. In a craft you have to do the basics yourself sometimes.
Re: Does the software industry learn?
#7Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
While I share the sentiment, there are plenty of perfectly valid reasons one might need or want to do this--I can't comment on that particular article as it seems to have moved off the front page.
A few things that could justify rebuilding the wheel as it were:
1. The thing doesn't work for the environment it's being used in (corporate network, obscure mobile browser, screen reader, whatever)
2. The thing doesn't work for non-Gregorian calendars
3. The thing doesn't work consistency across various types of clients (this reason gives me some nostalgic flashbacks to the early days of jQuery)
4. The thing is fine, somebody just wants to see how the sausage is made to learn of it
There's probably other reasons one would want to re-invent a common UI element. It's really hard to say how objectively good or bad a particular attempt is without context and more clarity on what metric it's being judged by.
Re: Does the software industry learn?
#8Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
Is that navel gazing? Is a carpenter talking about making a table in 2022 navel gazing? Maybe not the sexiest topic but I'm not sure that's the term I would use.
Re: Does the software industry learn?
#9Another story on the front page right now is "how I built a date picker". In 2022, people are still building date pickers. Imagine the progress our field could make were it not for the navel gazing, NIHing and pointless reworking.
Unfortunately the browser implementations of the HTML5 datepicker only make sense for an audience that understands the US date notation.
They can't be configured, as far as I know.
Re: Does the software industry learn?
#10I would also like to read a well-written analysis of COBOL, what it did right and what it did wrong. A problem the article doesn't mention, is that the percentage of still-programming developers who are young (<30 years) is higher than in other professions, for several reasons, so the lessons learned 15 years ago are often lost.
The few I know is the language tried to be so easy to read by anybody that it made creating abstraction impossible. If the problem fits cobol, you get a nanoSQL like DSL to manage on disk records nicely. If it doesn't (controlling multiple sub systems, ad-hoc state, graphs) it becomes a monstrosity. Over the years IBM and others tried to fix that by making tooling or having nicer languages transpiling down to COBOL, which lead to ever bigger monstrosity. I was shown old code base blending manual code + generated code + manual patch of the two.. it was a kind of office prank to let new guys read that for a day.