mbrodersen

Excel is brilliant.

In my view there is no such thing as “tech debt”.

The way I look at it, there will always be a delta between the code you have and the business features you want/need. Independently of whether the code was written 30 years ago or yesterday.

So the only question worth asking IMHO is how best to reduce the delta while maximising the business value/cost ratio.

If you talk about “tech debt” without talking business value/cost then you are indulging in “what would be fun to do” and not “what is the best next step for the business”.

The biggest lie by the way is “it will improve maintenance!”. Maybe for you (because you spent years rewriting it and know it inside out) but not for the unlucky next person who has to take over your code.

Another lie is using words like “Modern!” and “Brand New!” as if it is a good thing. I want the old software that has proven itself for more than 30 years. Not the “Modern! New! Shiny!” crap that has been implemented by bright eyed inexperienced beginners, is full of bugs, implemented using a “Modern!” framework that will stop being maintained in a year, and has 5% of the features of the “old” software.

“was previously fired from her job for sleeping in her car behind her place of employment.”

The cruelty of managers never stops surprising me. As long as she is doing her job and is presentable etc. what’s the problem? Worst case just ask her to park her car somewhere else?

Agree. I was offered a green card and a 6 digit salary to move to the US. I declined and instead moved to Australia. One of my best decisions ever.

In my experience there is a strong correlation between your ability to communicate clearly and your ability to write clean maintainable code.

The 10x developers I have worked with are all excellent communicators. The worst developers I have worked with most definitely weren’t.

Aussie here. Speak for yourself mate. The tech I am working on in Melbourne (Rostering/Pairing) is world class. We are routinely beating international companies 100x our size.

I work for a company where meetings are extremely rare. We only do formal meetings when everything else fails. It is one of the most efficient/productive companies I have ever worked for.

The least efficient/productive company I have ever worked for had formal meetings all the time. What takes a week where I work now would take 6 months there.

So no I don’t agree that meetings are automatically productive/useful in general. I am pretty sure you can measure how productive a software company is by the following formula:

Time spent working on projects divided by Time spent in meetings.

I have such fond memories of the ZX-Spectrum. I learned how to program machine code using it (hand translates from Z80 assembler) when I was 11 years old. No internet. Nobody I could ask for help. Just a book explaining how to do machine code programming on a ZX-Spectrum. The satisfaction of getting this working was amazing to me.

There is nothing magical about 40 hours. It just happens to be the number of hours that most companies (in the west) happens to choose for historical reasons:

https://www.okta.com/au/identity-101/40-hour-work-week/

Perhaps start with fixing the planet we are currently living on?

Not my experience at all. I have worked for two really fucked up companies. But the rest were OK and my current job is pretty good.

Not my experience at all. We have zero problems maintaining large 20+ year monoliths written in C++. It’s all about how you architecture the monoliths and how you refactor as needed to improve it.

If you don’t have the skills to create maintainable monoliths then you will guaranteed create an even bigger micro-services mud pile.

I recommend reading everything by Thomas Sowell. A true original thinker.

I wouldn’t be surprised if it is true. The larger the organisation, the harder it is to deploy well designed software architectures. Too many cooks!

> But when you say garbage like "100% nonsense" it's just fucking rude and against the rules here at HN. Don't say it again. Speak respectfully or don't speak at all.

I found that commment to be seriously rude and disrespectful. Yes I should have avoided the "100% nonsense" comment. However that doesn't give you licence to be rude and abusive in return.

Years ago I found the perfect tool for managing anything from small personal projects to large complex software development teams:

A prioritised to-do list.

It’s simple. It works.

It is my experience as a developer that the shorter the feedback loop is, the more productive I am. Fast auto tests are really useful for this. Being able to test against an in-memory DB instead of a much slower “real” DB is another example.

So it is kinda obvious to me that non-developers also will benefit from fast feedback loop software.

A colleague of mine is working on one of the worst software systems I have ever seen or heard of. It is a 20+ years old micro-services architecture. More than 50 services all interacting with each other in mysterious time dependent ways. It is almost impossible to debug or reason about. It took him most of a year to figure out how to reliably and automatically build and boot the system from scratch.

I have worked on systems with the same functionality but architectured as a single monolith + database. Maintaining that system was a walk in the park comparatively.

It’s a drop in the ocean. There are millions of programming jobs out there.

There are millions of programmers and programming jobs out there. More than 5 million C++ programmers alone. And then there are Java jobs, C# jobs etc. So the head line job cuts are a drop in the ocean.

Not my experience at all. The quality and experience of the team is IMHO the best predictor of code quality.

Declarative: Specify the result you want. Imperative: Specify (step by step) how to get the result you want.

Examples:

Declarative: I want a PC with the following code installed: X, Y and Z. Imperative: First upgrade X, then install Y, then uninstall W, then install Y and Z.

Years ago at university I wrote a small 2D circuit board drawing system in Fortran running on some old IBM mainframe computer. Only the first 6 characters of function names mattered so I ended up using the first 2 characters as the module/namespace and carefully encoded the next 4 characters as needed. I had never programmed in Fortran before but it was easy to learn. Fun times.

The company I work for is still using old Fortran code to simulate how long it takes for trains with a certain load to get from A to B given a sequence of gradients. I bet small bits of Fortran still lives inside many systems written in C/C++.

This is 100% pure nonsense. Haskell is not a category theory framework. 99% of Haskell programmers do great work without understanding or having any interest in CT. There are many mental thinking tools useful when designing Haskell (and other) software. CT is just one of them. And IMHO not a very useful one. I haven’t seen even one software design that benefitted from CT in ways that was better than straight forward transition systems.

Lambda Calculus is a much better representation of computation than Category Theory. I can teach somebody functional programming using Lambda Calculus fairly quickly. It would take a lot longer using Category Theory. I have studied quite a bit of Category Theory but I would still struggle to explain beta-reduction using Category Theory. Another better system to use IMHO is Martin Luff style Type Theory. Much simpler. Much more useful in practice.

There is a lot of software out there written in C. All of which needs maintenance. At work new C code gets checked in every day for software that runs major companies around the world.

Having said that, I would never recommend C as the language of choice for new projects.

For people who hate going to the gym but want to get stronger/healthier I recommend the book “Body by Science”. I have more than doubled my body strength following it. And only spending 15 min a week in the gym (!)