And you are here why?

/via http://www.commitstrip.com/en/2018/11/26/if-its-not-broken/ Funny cartoon, but the whole " Don’t refactor  craetionDtae ”, thing is a bit far-fetched, right You’d probably fix that typo without thinking twice about it, right? Wellllll, maybe not. After all, this might actually be something that is exposed to users (it’s in the API. Yay), so you need to refactor this  and  the documentation, but that’s OK, you can do that, right? Wellllll, maybe not. Because, now that you look, you notice that you’ve got  two  sets of typos,  craetionDtae  and  craetionDate , which means that refactoring means that you need to update  both  of these in the code  and  the docs, so now it’s  4  things that need to be changed, but it’s ok, you’ve got that, you can do it, right? Wellllll, maybe not. Because, now that you really look, you realize that  craetionDate  also exists as  craetionDates  (because, you  had  to pluralize the array, didn’t you?) and  craetionDateForUser  (because

Say you’re building something completely new and different, which can leave users feeling anxious and/or confused. How do you introduce it to the user, and get the user actually, well, using it? It’s a good question, and particularly relevant in our current world, where we are constantly being bombarded with information, with the volume and content thereof being ever-increasing. Mind you, the fact that we spend our days hunched over a computer and/or a phone doesn’t help at all — if anything it only emphasizes the sheer amount of cognitive load that we all live with on a day to day basis. In this environment, the last thing you want is to add anything to this cognitive load. As product developers, succeeding in this world involves either outcompeting the others, or making life easier for your users. Assuming that you  aren’t  in the business of being evil (please please don’t be evil!), your approach towards UX should focus on ensuring that the users  know  that they are doing

So yeah, do  you know what your company's goals are?  Yes, of course, “ Increase shareholder value ”, but do you know  how  your company plans on doing that? Stuff like • “ Increase the number of baby-strollers we sell by 67% this year ” • “ Convince at least 3000 people to buy our hand-selected peppercorns this month ”, or even • “ Get the work, do the work, get the money ”? /via http://rhymeswithorange.com/comics/april-6-1998/ You’d think this would be stuff that —  obviously!  — would be shared top down, but, then again, you’d probably not be surprised to know that this stuff  doesn’t  trickle down.  Mind you, it’s not necessarily malice. If you’re a tiny company, it’s just assumed that you know this. If you’re large, then there are just so many layers between you and the CEO/CFO that the message never makes it to you. And if you’re somewhere in the middle, everybody is just too busy to actually pass this information on 😠. ( And then, there is always malice, where somet

It was my first day on the job. This was a wee bit back, and the company I had just joined was having … issues … getting stuff out the door. “ Any day now ” had turned into “ It’ll ship in two weeks ”, and that was a cool 3 months in the past, and eventually, I got called in to help get stuff unstuck. So anyhow, it was my first day on the job, and I was poking around the repos, trying to figure out what was what. After a couple of baffled hours, I figured out that the development process seemed to be  eventual-consistency-git  — everybody developed against their own branch, and cherry picked from each other to get updates. A “release” involved nominating one developer (and their branch!) as the primary, and having everybody else stop work. The primary would then painstakingly merge in all the other branches,  maybe  resulting in something that worked. And yes, this was utterly bat-s**t crazy, but whatever. I put a little bit of order in place, just to get people working on the