sirwhinesalot

53 ms·

841.
by sirwhinesalot 5y ago
All very true, I'm not suggesting a monorepo for the whole org (that's dumb) but per project. If you have libraries shared across different applications, treat those libraries as fully independent products. No different from somet
842.
by sirwhinesalot 5y ago
You had 1 problem: Too many git repos. Now you have 2 problems: Too many git repos + a monorepo on top of all those repos. We tried this where I work to solve the issue of having 10x more git repos than people on the team. We got rid of the
843.
by sirwhinesalot 5y ago
You know C# has records too right? "With" and all.
844.
by sirwhinesalot 5y ago
Record classes and pattern matching get you 90% of the way there thankfully. Not perfect, but good enough. It's funny how much of a difference being able to write each case in a single line and have equality and all that stuff automati
845.
by sirwhinesalot 5y ago
PM: "We promised higher management that feature X would be done by The Date(tm)" DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future" PM&q
846.
by sirwhinesalot 5y ago
That's some victim blaming right there. If a project has tech debt it is because of management decisions 9/10. They are the ones promising higher management some feature would get done by The Date(tm) without consulting with devel
847.
by sirwhinesalot 5y ago
Code being a pain to work with, causing devs to quit and constantly causing bugs is costing massive amounts of money in lost productivity. Every hour the Senior Engineer wastes putting out fires is $100+ down the drain. Management simply
848.
by sirwhinesalot 5y ago
Understood, but in reality the PM is going to get kudos and your complaints that things that were delivered and paid for are "unfinished" are going to be ignored. Devs are pretty honest, management simply does not listen.
849.
by sirwhinesalot 5y ago
That's "paying the interest". Lets say you rush a component of your software out. Every time you make a change it causes massive headaches and issues. Lets say this decreases developer productivity by 5%. Then any new feature
850.
by sirwhinesalot 5y ago
The design of a house doesn't change every 3 weeks while it is getting built. House construction is usually only started after a massive amount of detailed design and planning is done. This is priced in. This is almost never true for s
851.
by sirwhinesalot 5y ago
I like the term debt because it makes it clear it is something that needs to be paid off and is accruing interest. Meaning the longer we don't pay it the more expensive it gets, until almost no development time is going to the "pr
852.
by sirwhinesalot 5y ago
That is how it goes in the end with any estimate. If it is overestimated the product is delivered with high quality. If it is underestimated the product is delivered with low quality. You can always buy time with technical debt. Our industr
853.
by sirwhinesalot 5y ago
Just to clarify what I mean by "same project, different requirements": you deliver a dashboard to customer A, who is quite helpful and clearly communicated what he wanted. It took 6 months. Customer B asks for a dashboard like tha
854.
by sirwhinesalot 5y ago
The article was doing pretty well until they brought up historical data. The exact same software project done twice can take wildly different times because the team and/or the requirements are different. That's the whole point of
855.
by sirwhinesalot 5y ago
They need to stop locking people into their ecosystem and generate code you can get out and hand out to a developer if necessary. No-Code / Low-Code / Full-Code is a false trichotomy anyway. There's no reason why visual codin
856.
by sirwhinesalot 5y ago
I guess that's part of the reason I enjoy reading about and experimenting with old hardware like the Amiga and old consoles. You could learn how the whole machine worked. It's a wonderful feeling that just doesn't exist on mo
857.
by sirwhinesalot 5y ago
I don't want to print on a breakpoint, that is again useless, the cause of the problem might be far removed from the location of the exception. I want multiple breakpoints, each of which prints data, so I get a log of the behaviour of
858.
by sirwhinesalot 5y ago
That's useless, debugging a NPE is about figuring out where the null originated. Breaking on the exception is too late.
859.
by sirwhinesalot 5y ago
Lark is amazing... But it's also one of the best LR parsers out there and I would guess that mode is used a lot more than the Earley mode. Either way, I have never used a better parser generator. It has the best usability and incredibl
860.
by sirwhinesalot 5y ago
I rarely use a debugger. The experience is just awful in almost every debugger I've used. For low level code where you really want to see all the program/function state evolving over time, they can be useful. Your Java program thr
861.
by sirwhinesalot 5y ago
Neat, though this just seems like PEG with extra steps and more pain. Still this answers my question. Thanks!
862.
by sirwhinesalot 5y ago
Early and similar algorithms give you a parse forest rather than a parse tree. For a programming language you don't want to have your grammar be ambiguous. When Early gives you a bunch of alternative parse trees, how do you disambiguat