When I was younger and struggling with issues, I did exactly this - plot my happiness on a graph. It was one of the few things that helped me get through a day, seeing that there are ebbs and flows, and for every low point there's likely a high point coming up.
"It’s a bit ironic considering that yesterday Marcus took to Twitter to say his credit card was hacked. So clearly not all hacking is acceptable in Marcus’ book — only hacking that supports the company’s business objectives."
I got the feeling that it was mostly PR to point out that his card was hacked. He was quoted as saying that had he used Paypal to pay instead of his physical card (which had extra security chip in it) he would have been secure.
I had the same reaction. Unfortunately the general public is ignorant about the different definition of hacking here. The author is likely ignorant about it too and not purposefully trying to deceive people.
I don't think it's a joke at all - I know lots of companies and people (myself included) who stress their culture and fit so much that technical skills often fall by the wayside. Sure, we want to know if you can code, but that can usually be figured out with a 15 minute white board test. If you're truly a pain to work with, unable to work in a team environment, or generally not collaborative, you probably won't get a job at my company.
Conversely, if you're a self-motivated learner, a good team member, and able to contribute, but don't quite have the technical skills we're looking for, we'll gladly take a training hit (usually 2 to 4 weeks) to get you up to speed on language X in exchange for an engaged and valuable employee.
Well, as you say, you do check if they're "good people and nice to work with" - the post said pretty much that, because "being the kind of person I'd like to have a beer after work" is pretty much the same emotional reaction as "being the kind of person that is good and nice to work with", and isn't related to the fact if you're actually having beer after work with anyone.
Related, I like to leave non-working code or tests at the end of a day so I can easily find where I left off. For some reason when I try to build / test and the errors pop up I'm able to immediately pick up where I left off. A combination of a bookmark and the Zeigarnik Effect I guess?
I like to set external-facing deadlines. I'll do things like tell my department I'm going to do a presentation on technology X in two weeks, and then start learning about it. If I don't get it done, I have to tell 20 other developers why I have to cancel the meeting they've all accepted.
This is part of the motivation of team and peer-accountability in some of the agile methods like Scrum / XP / Pair Programming. If you feel personally responsible to someone else, you're likely to follow through. A good way to do this with personal projects is to find a partner - I work with a designer on a lot of my personal projects, and telling him that I'm going to get X done helps, as well as seeing the time and progress he's invested in the project.
One of my favorite stories told by our software consultants (the people we send to client sites to train how to use our software effectively):
One day he went to a customer's site to train them on the new version of our software, and met with one of the bookkeepers of the company. He showed her a report that we recently added a column to as part of a feature request from our clients, and she started crying. He was asking her what was wrong, worried that we did something terrible. She replied: "You just saved me 3 hours a day. Now I can go home when my kids are home from school instead of after supper".
Just because we're not saving babies doesn't mean we're not making people's lives better.
I work in ed-tech and while a school contract is no where near the size of a business contract, we regularly hear from school administrators how much of their day they get back.
You just saved me 3 hours a day. Now I can go home when my kids are home from school instead of after supper.
The ugly part of this is that we rarely know whether we're saving time or cutting jobs (and depriving people of income). Between our low level of access to the relevant information, and the execrable leadership the world currently has, we can rarely know that.
When the world has good leadership, technological progress (even small victories) save time and create wealth. When it has bad leadership, it ends jobs (that are never replaced) and helps the working world shut itself down.
In a shop with only one accountant, you're saving her three hours a day.
In a shop with 100 accountants, 30 of them just lost their jobs.
The trouble with our work is not that we don't know whether or not it's doing good or bad, it's that it's almost always doing both at the same time. Determining whether the good outweighs the bad is both subjective, highly fraught with egotism, and treads uncomfortably close to rationalization and playing god.
If the 100 accountants are smart, they'll spend half the day studying for their CFA exams and not let management know that they're overstaffed.
You're right, though. That's the fundamental problem. I can always get on board with automating (and thus "killing") undesirable work. I can't get on board with depriving regular people (below $100,000 per year) of an income if I can help it. I am aware that society needs to cut jobs and that that's a really good thing; I just wish it would train up before trading up.
It depends what you mean by "jobs". If you mean it in the headcount sense, then yes, that's bad. Good leadership should inform its employees of how technology is impacting its operations. That way employees have an opportunity to prepare and to find new ways of adding value, so they don't have to leave once their old role becomes obsolete.
But if you mean "jobs" in the "having a person do this specific action" sense, then I couldn't disagree more. Progress isn't made unless jobs (in that sense) are cut. The human mind has such amazing potential and we shouldn't waste it doing things that can be easily automated.
People not doing something any more is not necessarily "progress". People who enjoy their job, or for whom that job is the only thing to keep them from hitting bottom, do not have an 'amazing potential' that will improve their lives to use elsewhere.
We think all the time about how to automate things, but rarely or never about how to make places for other people at the feast. When it comes to distribution of surpluses, we get all vague about "progress." Why are we are so specific and concrete and active on one side, and so vague on the other?
When something is automated, we are not allocating the excess production to letting people spend time with their kids (or whatever those people want to do with it). We are cutting positions, hiring temps without benefits, hiring cheaper contractors from elsewhere... and keeping the change.
Because the little people are not defined as really part of the company, but as supplies and tools for the company's operations. From interview to layoff, they are at best a necessary evil, held at arms' length. The only people who are really part of the company are the powerful ones, who allocate the increases to themselves because they had the vision and the capital and they are the only ones who deserve it. And assuming a just world, those who are excluded and may have trouble finding new jobs deserve what they're getting as well.
Good leadership is leadership of humans, and incorporates concern for the humans being led. Just having lots of capital and using it in any way that gives you profit is not leadership, it is merely ownership.
It's not bad to be wealthy, nor is it bad to grow the pie. The problem is that interests are so profoundly misaligned that "progress" means allocating a higher and higher proportion of all surpluses to a ruthless subset of the wealthy. If we wanted more progress, we'd work on aligning interests better.
Some theorize that automating people out of jobs, "frees" them to find some more fulfilling job/activity. As our current economy illustrates, "it ain't necessarily so".
Yeah - fortunately our company is small enough where we can hear stories like that from our support/sales staff, but in larger companies developers are so far removed from the end user that we have no idea how much of an impact we actually make in people's day-to-day.
