"If you delegate all your IT security to the InfoSec, they will come up with Draconian rules"
Rules of thumb for a 1x developer
451–460 of 505 posts
Re: Rules of thumb for a 1x developer
#452Earlier quoted context omitted.
It's unlikely that this went entirely unnoticed for 4 years, and I would guess that when the problem was understood, someone did the math on staying the course, versus starting over or reversing course. And after all the internal calculations were complete (which factor in way more than technical effort by a small dev team), they intentionally stayed the course. This is probably an extreme example because an internal…
I dont know ... I have seen enough impulsive random decision to be made. Including high price ones, including by very smart individuals. It is just not true that someone always runs the math and then decides by weighting pros and cons.
But having worked in and around these kinds of teams and companies for most of my 25-year career, I can tell you that it's "often", in my opinion/experience.
Re: Rules of thumb for a 1x developer
#453"Rule 11: Which database technology to choose: Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL" I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.
The issue with SQL is that the DB needs to be designed first. But when it is done correctly, the advantages are numerous.
Re: Rules of thumb for a 1x developer
#454Earlier quoted context omitted.
... and this system was responsible for billing, and many other things....
and? That's not PGSQL fault, is the DB architect (or lack of) fault. You definitely can drive the safest car in a ditch, no?
Re: Rules of thumb for a 1x developer
#455"To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated" I would love to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue fo…
There's a roughly ~12,000-word postmortem document that took an additional 2+ months to produce after the fact, which the OP has lightly quoted or summarized from in his post (including what you quoted). It really is an impressively magnificent failure at scale, but there's nothing really fundamentally earth-shattering about how this project went so far off the rails. Mistakes were made, but IMO nobody was outrageous…
Re: Rules of thumb for a 1x developer
#456Earlier quoted context omitted.
No, the original chain was about the choice of being full-gas all the time for your employer or pace yourself.
Let me sum up how I saw it go... -you can get more done if you avoid addictive black holes for attention --if they don't want you playing around they should pay you more than the salary you agreed to work for ---yup, still getting paid the same. company is getting theirs, go get yours (I think this reply was actually sarcastic) ----how do you live with yourself -----if you have integrity you're dumb ------most people…
Re: Rules of thumb for a 1x developer
#457Earlier quoted context omitted.
Becuase top talent usually don't get desperate. It's a bad way to judge someone, of course, but there aren't many good ways, and when hiring, you want to play it safe: not hiring a good candidate is way better than hiring someone who turns out to be bad. So, if you notice something that looks like it might have been a red flag, you take notice.
"not hiring a good candidate is way better than hiring someone who turns out to be bad." is it though? CA is at-will employment, so there's literally nothing stopping a company from firing someone that isn't working out (besides timidity on the part of the person who would have to do the firing). "when hiring, you want to play it safe" personally, i'd rather tell some people it's not working out than miss out on incr…
Last I checked, I was 9700 kilometers away from California. Not everybody on HN is from Silicon Valley.
> personally, i'd rather tell some people it's not working out than miss out on incredible talent because i'm too scared to fire someone.
Then you've never seen one bad hire destroy whole teams.
> reading 'desperation' into someone's application is projecting your own fears and experiences onto theirs without actually taking the time to learn more.
This thesis has no null hypothesis. The same arguments could be applied to about anyone who's perceving any emotions from other people, in any context, aside from listening to a person narrate his emotions out loud. See, none of us have any emptathy or eye for emotion, we're all just projecting something of our own. And if you, or anyone, has any counter-argument against this clearly absurd statement, the same counter-argument could equally rebute yours as well.
Re: Rules of thumb for a 1x developer
#458"Rule 11: Which database technology to choose: Choose SQL when you need to do ad hoc queries and/or you need support for ACID and transactions. Otherwise choose no-SQL" I think it should be the contrary: SQL by default, no-SQL if you have a specific need and know what you are doing.
I so much agree with you. The issue with SQL is that the DB needs to be designed first. But when it is done correctly, the advantages are numerous.
Because if you don't your database essentially becomes a write-only vault since you don't have any idea of how your data is stored or was stored in the past.
Re: Rules of thumb for a 1x developer
#459Sometimes you don't have or don't want a server, but still want to avoid the issue of wedding business logic to the UI.
With web apps my strategy is to treat business logic as a separate library housed in the same project. I'll have a "SomeBusiness" directory and just import it across the project like I would a third party library.
Re: Rules of thumb for a 1x developer
#460Earlier quoted context omitted.
I knew two 10x developers at my previous job. One of them was humble and a great mentor and elevated everyone around him. One was a grump who made everyone around him feel stupid. Imo toxicity is independent from productivity.
Same experience. I learned quite a bit simply by sitting next to an exceptionally good and exceptionally nice developer who was at least a decade older than the rest of the team and enjoyed helping others. He rarely got stressed even in crunch times and that put rest of the team at ease.