Eighteen years here. I am not American but I think this is a holiday that we can all celebrate as reminder that we should be grateful for what and specially for who we have, independently what we don't have.
Readit Newshuherto commented on Python is not a great language for data science blog.genesmindsmachines.c... · Posted by u/speckx
Isn't the author saying that Python + Pandas is almost as good as R, but Python without Pandas is less powerful than R.
I can't help to conclude that Python is as good as R because I still have the choice of using Pandas when I need it. What did I get wrong?
huherto commented on Python is not a great language for data science blog.genesmindsmachines.c... · Posted by u/speckx
For what is worth. The Kotlin folks have been adding some cool features and tools for data analysis. https://kotlinlang.org/docs/data-analysis-overview.html
huherto commented on We stopped roadmap work for a week and fixed bugs lalitm.com/fixits-are-goo... · Posted by u/lalitmaganti
I love the idea, but this line:
> 1) no bug should take over 2 days
Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.
That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one.
Also, I tend to attack bugs by priority/severity, as opposed to difficulty.
Some of the most serious bugs are often quite easy to find.
Once I find the cause of a bug, the fix is usually just around the corner.
I do agree that you should be able to fix most bugs in 2 days or less. If you have many bugs taking longer to fix, it may be an indication that you may have systemic issues. (e.g design, architectural, tooling, environment access, test infrastructure, etc)
As a very long-time Perl developer and FOSS contributor, I think this blog post is incorrect about whether Perl 6/Raku was a factor in Perl's decline. I think Perl 6/Raku did a few things that hurt Perl 5:
1. It pulled away folks who would otherwise have spent time improving Perl 5 (either the core or via modules).
2. It discouraged significant changes to the Perl 5 language, since many people figured that it wasn't worth it with Perl 6 just around the corner.
3. It confused CTO/VP Eng types, some of whom thought that they shouldn't invest in Perl 5, since Perl 6 was coming soon. I've heard multiple people in the Perl community discuss hearing this directly from execs.
Of course, hindsight is 20/20 and all that.
Also, even if Perl 6 had never happened the way it did and instead we'd just had smaller evolutions of the language in major versions, I think usage would still have shrunk over time.
A lot of people just dislike Perl's weird syntax and behavior. Many of those people were in a position to teach undergrads, and they chose to use Python and Java.
And other languages have improved a lot or been created in the past 20+ years. Java has gotten way better, as has Python. JavaScript went from "terribly browser-only language" to "much less terrible run anywhere language" with a huge ecosystem. And Go came along and provided an aggressively mediocre but very usable strongly typed language with super-fast builds and easy deploys.
Edit: Also PHP was a huge factor in displacing Perl for the quick and dirty web app on hosted services. It was super easy to deploy and ran way faster than Perl without mod_perl. Using mod_perl generally wasn't possible on shared hosting, which was very common back in the days before everyone got their own VM.
All of those things would still have eaten some of Perl's lunch.
True. Adding to these. Perl6/Raku suffered from the second system effect. Described in the Mythical Man Month. Larry and company were over confident with their previous success.
huherto commented on The Pragmatic Programmer: 20th Anniversary Edition (2023) ahalbert.com/technology/2... · Posted by u/ahalbert2
A classic book. I learn something new each time I read it.
Also, Dave Thomas, one of the authors, is looking for a job.
> So, I'm looking for a job!
> Internal or external consultant, devrel, training, team fixing, design, architecture. WFH or travel the world.
> So, if you know any company that has a Dave-shaped hole, please email me. Some more about me on my site. Links below.
> Many thanks.
> email: dave@pragdave.me
I know that there are many reasons for people to work after 65. I also know that sometimes life takes surprising turns. But it makes me nervous to see people so capable as Dave that are well known in our industry looking for a job. What is the hope of the rest of us ? I love software engineering but I still hope to be able to retire to work on my own projects.
huherto commented on The kind of company I want to be a part of dvsj.in/my-company... · Posted by u/ctxc
The essence of this post is about craftsmanship, value, and caring about what you're doing. It's really hard to put this into words. There's certainly a gradient and trade-offs to be made. In most businesses, the priority is to make money. This is not bad. Business owners deserve to make money for their efforts.
It's always been the case that "bean counters" will optimize to increase profits. If you want a superior product, you have to pay for it. Particle board furniture sold at Walmart certainly wont last nearly the same way as hand-crafted pieces by Gomer Bolstrood. The contrast is dramatic. Mass produced disposable products vs one-of-a-kind products built with a high attention to detail.
The idea of paying more for quality doesn't seem to apply to software. Maybe I'm romanticizing the past, but I believe it did once. I believe that the software developers of yore cared more about their craft than most of the ones employed today. I think they had to. If a product didn't sell, it was pulled from the shelves. It would be dropped by distributors.
Somewhere along the way it's become more important to prioritize minimal time to market, and minimal viable products. People who care about software quality still exist, but they are slowly being squeezed out by others who don't. Profit, growth, and market share have become more important than providing real value to users.
"Quality is Free" was repeated over and over by my college professor back in the 80s. I guess he was fan if this guy. https://archive.org/details/qualityisfree00cros.
Similarly in software. When a software product is well crafted/engineered, it has less defects, it is easier to understand and modify, saving a lot of time and effort. I do not see that anymore. I see a lot of smart young engineers but they are managed in a way in which the craft doesn't matter and what matters is how many story points you do.
huherto commented on Show HN: Venturu – Zillow for the market of local businesses venturu.com... · Posted by u/lifenautjoe
Congrats Joel! This is such a great and useful idea! Godsped!
huherto commented on Modular monolith and microservices: Modularity is what matters binaryigor.com/modular-mo... · Posted by u/BinaryIgor
I think the big problem no one speaks about is the name "microservices" was incredibly poorly named.
Your design goal should not be "create the smallest service you can to satisfy the 'micro' label". Your design goal should be to create right-sized services aligned to your domain and organization.
The deployment side is of course a red herring. People can and do deploy monoliths with multiple deployments and different endpoints. And I've seen numerous places do "microservices" which have extensive shared libraries where the bulk of the code actually lives. Technically not a monolith - except it really is, just packaged differently.
This is my take too. Just because of the name, people try to make them as small as possible and we end up with too many of them.
> Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don’t know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important.
> Now I cannot prove the cause and effect sequence because you might say, “The closed door is symbolic of a closed mind.” I don’t know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing—not much, but enough that they miss fame.
I guess you need focused work to make progress but once in a while you need contact with others to find inspiration or new ideas.
Another one similar phrase(kinda). "If you want to go fast go alone. If want to go far go together". African proverb.