jeltz

15 ms·

331.
by jeltz 11mo ago
In my experience a lot of bad was bad even when it was written. And that writing good code is often cheaper (within reason, perfection is bad) over any project bigger than a couple of months. The payoff from having good code shows up very q
332.
by jeltz 11mo ago
Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.
333.
by jeltz 11mo ago
Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.
334.
by jeltz 11mo ago
Doesn't that just mean you are underpaid?
335.
by jeltz 11mo ago
Having tried both I would rather be ground up again than just accepting my fate. I rather die fighting than the alternative.
336.
by jeltz 11mo ago
It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.
337.
by jeltz 11mo ago
> Are we automating this problem and going all-in on the long term costs? I feel that is a very likely scenario.
338.
by jeltz 11mo ago
Why would industrially or restaurant made ones be any nutritionally worse? Processing is processing no matter who does it and processing does not automatically make something less healthy or raw meat would be healthier than cooked.
339.
by jeltz 11mo ago
Yes, that is an issue they have but I do not think it is the main issue. In these orgs even week rounded engineers can be made to write bad code.
340.
by jeltz 11mo ago
Of course you should not wait around. I think rather the opposite that the engineers should be more involved in working on the requirements. The issue is more rushing and being expected to magically just conjure something. Changing requirem
341.
by jeltz 11mo ago
Sounds pretty much like my experience with the official Signal app. It is a mess too and I only use Signal/Molly because I have friends who use it. But sadly the competitors are as bad, just in different ways. Why has nobody yet manage
342.
by jeltz 11mo ago
It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper
343.
by jeltz 11mo ago
Yes, I have. I have also worked at placed which do not. And the difference is night and day. The places which respect engineering are more fun to work at, deliver better features for less cost and the code is better. Only places which can d
344.
by jeltz 11mo ago
100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clea
345.
by jeltz 11mo ago
Sadly a lot of engineers have been indoctrinated into this mindset and I have had to fight quite many battles to conceive my fellow engineers that missing a deadline is not the worst thing in the world.
346.
by jeltz 11mo ago
Yeah, I in my experience this is the root of most bad code. People rushing. And it is not even necessarily faster to rush, since often working slow and methodical wins the race. I don't get why we as managers and engineers have just ac
347.
by jeltz 11mo ago
I don't really buy that this is the main reason. A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed and with the need to ask other people frequenyly. Even if you do not know th
348.
by jeltz 11mo ago
Yeah, the Signal team's roadmap seems very strange to me as an outsider. There are some low hanging fruits which they just seem to refuse to fix. And given how in this case Molly could fix it it cannot have been that hard to fix.
349.
by jeltz 11mo ago
Signal's official Android app does not support being linked, only the iOS and desktop apps support that. This is why I use Molly. I would ideally want to not have one device being the master and the rest linked to it (e.g. Element can
350.
by jeltz 11mo ago
Not sure why car chases are necessary to solve this problem. Just arrest these people in their homes. Those videos are enough evidence for arrest and conviction.
351.
by jeltz 11mo ago
I did not include any negative or positive about DHH since I have never interacted with him. He is unimportant to Ruby compared to Evans other than for historical reasons. Evans is a guy who has done a ton and still does a ton in the Ruby c
352.
by jeltz 11mo ago
As far as I know that is really the only example. And to clarify it is about a struggle between who controls Rubygems and Bundler, not Ruby itself. A key component to be sure but maybe not that relevant to this discussion when the ones runn
353.
by jeltz 11mo ago
That is clearly not Jeremy Evans. Maybe a funny joke if that innocent commenter had not been downvoted to hell.
354.
by jeltz 11mo ago
In every interaction with Evans I have had he has been super nice and welcoming to contributors. Maybe he had a bad day.
355.
by jeltz 11mo ago
No idea, Jeremy Evans is a really good coder and a nice person. Also a much more influential voice in the Ruby community than DHH.
356.
by jeltz 11mo ago
Ruby is not and has never been led by DHH.
357.
by jeltz 11mo ago
They do and it is often entertaining.
358.
by jeltz 1y ago
Yes.
359.
by jeltz 1y ago
No, C is not fine. It is a really bad language that I unfortunately have to code professionally.
360.
by jeltz 1y ago
One of the only studied made so far showed lower actual productivity despite higher self reported productivity. That study was quite limited but I would take self reported productivity with a huge grain of salt.

More ›