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...
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.
> 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.
> 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.
> 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>."
Funny how a "free" PDF book can be sold out.