beryilma

> Sold out, please go back and pick another option.

Funny how a "free" PDF book can be sold out.

As much as I appreciate the author's effort, if I have to enter my email to get the "free" book, then the book is not free.

One might even argue that a Turing Machine (computers) is really one dimensional.

This is 5 times more readable than FP example above for the same computation. The FP example uses variable book(s) five times, where using it once was sufficient for SQL. Perhaps FP languages could have learned something from SQL...

Github, nodejs, and PM2.

I can deploy to my local machine AND to EC2 with a single deploy command using PM2 configuration facilities. This works quite well for side projects.

I also have nginx and postges running on both locations with local (to the server) database connections without opening unnecessary ports to the world.

> Lately, I've built simple websites and small web apps in vanilla Javascript and CSS

Any public links?

a.k.a. Emacs.

Out of curiosity, what level of $ amount are you talking about?

> but I started to realize that pushing 50 and being as cynical as I now am, I'm pretty much unemployable as an IC.

Well that's me. My theory is that it is not age that makes one unemployable in the software industry, but the unwillingness to put up with shit cooked up by bunch of 25 year old CEOs, CTOs, and the like.

"Uncle Bob" is not a software engineer (as he calls himself) and anything he says on the subject is theoretical at best, and snake oil at worst. Can anyone point to any substantial piece of code that he wrote before he can be taken seriously. The code pieces at his GitHub repos, other than style, etc., are just simplistic stuff.

It is probably OK to be thinking on issues related to a field (i.e., software engineering) without being a practitioner in the field, but producing fads-du-jour and selling them as solid (pun intended) theories and expecting to be taken seriously is just ludicrous to me.

The problem with software estimation is that the requirements change constantly because customers often don't know what they want until they see a prototype or a mock of the system. Then, you constantly get unspecified, subtle requirements in endless emails starting with "I would also like to ...", without the customer realizing what they are asking for and how that might effect the deadlines.

Relevant HN discussion: https://news.ycombinator.com/item?id=42592543

> People who stress over code style, linting rules, or other minutia remain insane weirdos to me.

Until you open a file that has 10 different coding styles from 5 different developers. Just the variations of variable naming schemes alone in individual code files that I see/edit, would drive anyone crazy.

> Yes, you guessed it, let's go with Electron and CoffeeScript.

> The main tech stack is still CoffeeScript, but we changed the UI framework from React to Riot.js.

> I've installed Babel, Mocha, ESLint, and added libraries via npm.

> I've rewritten my entire code base from CoffeeScript to ES6.

> The introduction of MobX, a state management library, and the introduction of Flow, a type checking system.

> So I rewrote everything in TypeScript, including my own libraries.

> Anyway, I'll be replacing my own components like Button and Toolbar with Material-UI ones.

> It's time to rewrite everything to styled-components.

> It's time to rewrite everything to useXXX.

No wonder why these software projects (personal as well as professional ones) are 6 years late. It may be a good learning experience, but a terribly inefficient way of developing software.

> June 28, 2025: All new developments must comply.

I don't know what the consequences would be for companies, but there is no way this is happening by June 28.

> A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered.

I totally believe this. I see zombie programs at my employer, including the ones that are currently making a profit, that just don't know yet that they are dead. The Jira model of non-ownership software development being a leading cause in my opinion...

> We handle all the management, including rebalancing and tax-loss harvesting—proactively selling losing stocks to potentially save on taxes

- For a non-retirement portfolio, isn't rebalancing is a taxable event? Rebalancing by selling stocks and buying others is not the best approach. Isn't it better to rebalance by shifting the focus of new investments based on a strategy?

- I think it is misleading to present tax-loss harvesting as a way of saving on taxes. I don't know why people present it this way. In order to "save on taxes" you have to realize (i.e., sell stocks at) a loss first...

> I've noticed quality issues in your code recently...

Why is it always the report who is the source of the problem and not the manager?

How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager.

Have a hard conversation with yourself first before blaming the reports.

I really believe in the ownership model, which is why I hate the Jira ticket-based development model so much.

There was a time in my company where a single developer, who owned the product, would ship an entire app in a year. Now we have a "cross-team" where you have to constantly manage all feedback and try to shut down stupid ideas from getting into the product. I really hate design by committee: all talk and no ownership.

>> "Hi, I'm one of the 100K alumni who went to the same school as you did, can we do coffee?" is

I have absolutely gotten similar requests from students through my Alumni organization and have accepted them in the past. I don't see a problem here.

Here is a direct quote from a request that I have accepted in the past(redacted a little): "Hi <name>, I am a MS in CS student at <university> graduating in spring '25 and I saw your profile on <university>'s alumni page. I'm pursuing a career in software engineering and I'm wondering if we can connect and chat sometime about your career and the culture at <company>."

> because all their relationships are transactional and they aren’t offering anything of value

Why is a transactional relationship considered bad? And why would one consider a transactional relationship as something not offering value?

I don't like small talk, but if I like the person I would try to help them anyway with their transactional request, with the expectation that I might have a similar transactional request at some point in the future. If the relationship is equally transactional in both directions, I don't see a problem with that.

I know of a graduate-level software engineering course at a reputable US university, where getting kicked out of the project group is a possibility and gets the person an automatic F grade.

Raspberry Pi 400 as my home internet and exercise video computer.

What are the dumb phone options in the US? I want to get one.

There must be a German word for what the article does with its title against its content.

Performance reviews are a scam. I know from my manager days that the performance ratings at my company were determined even before any manager or self-reviews were written. Reviews match the performance ratings; not the other way around. It made me sick.

Along the same lines, if you are a bad student for whatever reason, the best thing you can do to improve your grades without any extra work is to ask questions during class and talk to your teacher before/after class. I guarantee results...

This has everything to do with propagation of significant digits.

Since the data in the mentioned experiment are "exact" measurements without uncertainty, the data is being treated as infinite (or rather, machine) precision, where the percentage difference would also have to be reported at machine precision, which is what the author is getting at:

>>> 100 * ((37/45) / (312/401) - 1)

5.676638176638171

However, assume that the same kind of data came from a sensor with some uncertainty (say, 2 digits precision), then you could have, within that uncertainty bound, L = 46 (instead of L = 45, etc.), R = 400 (and still L+R = 446), which would give

>>> 100 * ((37/46) / (312/400) - 1)

3.121516164994431

Obviously, this is a huge difference, which is why propagation of significant digits needs to be considered if there is any uncertainty in the data. And in that case adding more digits will not buy you anything.

The author's case is a special case where the values are "exact" and therefore you need more precision in the reported percentage value. But it is often not applicable in science when measured data has uncertainty.

This seems to be written by someone who has no idea of what they are talking about. Propagation of significant digits over algebraic operations is a solved problem. Adding more digits than the minimum necessary significant digits does not get you anything extra. Literally the first class in Physics 101 courses teaches this.

Not that it is everybody's cup of tea, but Emacs Org mode has Scheduled and Deadline dates, along with Effort estimates.