241–250 of 322 posts
Earlier quoted context omitted.
The fact that you are calling him "Mr" Peterson says a lot of depressing things about you.
What is the context of this comment? I don't know who Jordan Peterson is or what he's done.
https://www.munkdebates.com/The-Debates/Political-Correctnes...
How to successfully roll out a product/site. Released "Version 2" which was an entire newly built system that we worked on for an entire year (we also thought we were "agile" btw). This completely crashed and around 10K users were unable to use the product for almost 2 weeks. We did plenty of things right but we also failed. Biggest Lessons learned: 1. Release features and changes in manageable incremental chunks 2.…
What is an APM in this context? Google just tells me about Alternative Payment Methods.
New Relic, AppDynamics, and DynaTrace are a few vendors in this area.
Earlier quoted context omitted.
I eat at restaurants everyday. I know I shouldn’t but it’s hard to change lifestyle...
You shouldn't if it has negative financial or medical effects on you. I eat out exclusively, and do so for less than the cost of groceries and with fantastic effects on my health, and I'm doing so in a very high cost of living city, too.
Sure, it's oversimplified, sure some "bad-seeming" things are good in the long run, etc. But I find the fork part interesting to thing about - the fact that one little thing can spiral your life of in a completely different direction.
Earlier quoted context omitted.
As a user I beg of you not to sacrifice usefulness and features for Pretty. Seen way too may times where stuff was rewritten to look better but usability suffered. Case in point: Walmart recently redid their self checkouts. The new system looks a lot better and I like it if it did not take 3 times as long to pay. It even took forever compared to the old one to register cash being inserted. And there were several comp…
Waitmart takes even longer with these systems? I generally always go to cashiers for that reason. I feel like I'm becoming the minority who would rather deal with an actual person than an automated system most of the time, and I develop automated software.
Documentation is like sex. If it is good, it is good. If it is bad it is good
1) Why (requirements, decision points)
2) What (use cases, interactions, external APIs)
3) How (internal APIs)
4) Who (SMEs, owners, servers)
And don't waste people's time; don't document things that are obvious.
The need for exponential back off when retrying a connection to a server. Learned after deploying to millions of client devices :)
I will sometimes use a "pseudo exponential" like 1,3,5,10,25,50,100 and hold there. Of course, if you're trying to avoid collisions on a shared resource, the classic algorithm is pretty good.
I learned the hard way that sociopaths and psychopaths are real, they're not all monstrous murderers, and some of them you may even call friend or family.
Sadly, after more than 20 years building software, _NEVER_ trust a business person. My faith in humanity had to have me bitten by this the hard way more than once.
Could you elaborate a bit more? I’m not sure what to take away from this.
Lumping it all into "business person" isn't very useful because there are a lot of business people. So maybe a few specific examples can help.
Account managers and salespeople: while their stated job is to help you with customer issues, they're actually paid to sell/upsell you, and even if they're not, they're evaluated on selling/upselling you. This means they're likely to stretch the truth about the product they're selling in order to close the deal. So when you're interacting with salespeople, you can never 100% trust what they tell you, because they're not actually trying to help you.
Business development: the company they work for has an agenda. That agenda won't be obvious to you. Maybe they're asking you to come in to do a demo because they want to consider partnering with/acquiring your startup. Actually, they're spinning up a team to just build it themselves, but they want ideas. The problem is you have no way of knowing which is which.
HR: you know the common wisdom, they're there to protect the company, not you, and often that makes a huge difference.
Someone hiring you for contract work: they do want the work done, but they're trying their hardest to avoid paying. That means every ambiguity in the agreement becomes something they might try to leverage against you.
In other words, don't trust someone until you understand their hidden motive. "Business people" just tend to have more of them than your average person.