We all know the trope about job hoppers. They're unreliable, lack loyalty, etc. But what about the employee with 10+ years of tenure? Often times this person is disgruntled due to years of meager raises and lack of recognition. Further, they are the epitome of 1 year of experience repeated 10 times.
We all know this person. They're hard to work with. Yet, there they are.
What have studies shown about the rat who spends too much time in the maze and never gets the cheese?
Find the person in your org who has high impact, and does NOT want the spotlight. Reward that person on their terms.
My mother in law likes to decide what you want for Christmas. Don't do that. Ask the kid what he wants for Christmas.
Only recognizing the people in your org who are making noise is lazy leadership.
This is called Raptor's rule, because the lizard brain can only see things that move.
As a developer, there are so many occasions when you'll be lost in the maze, and you need to reach out to a fellow dev for direction. Devs being devs, they'll oftentimes go to great lengths not to talk to you.
A 15 min zoom call can save hours of fumbling around in the dark, yet we face so much friction in getting someone to agree to it.
"Look at the Jira ticket", they'll say. Yes, I did, there's not much there.
"Read the documentation", they'll say. Okay, where is it? Oh, there it is. Surprise, the documentation is lacking and doesn't help much.
"Here's a git repo with some samples." Guess what, your utility apps rarely "just work".
I know, I know, part of being a developer is learning to navigate a landscape with limited guidance. Just figure it out And we will, eventually. But at what cost?
As a developer, your value to the company is greatly correlated with your willingness to jump on a zoom call.
There is one team member who's been around long enough to know the secrets of the fire swamp. But guess what, he's tasked with the most critical projects, under the most schedule pressure. If everyone bombards him with questions, he'll never get his work done!
We're hiring, we need to grow our team from 5 to 25 developers. At one point does it make sense to task your most experienced developer with being a concierge to the other developers? Senior team members provide more value by boosting the productivity of the larger team. Be willing to zoom at a moment's notice. There's more business ROI there than telling people not to bother you because you're busy with your own project.
I've seen leaders encourage this behavior. "Don't bother Jeff, he's focused on a critical project and can't be distracted." Now Jeff has a license to ignore you or tell you to buzz off.
The developer experience is a concept that's gotten a lot of attention these days. As a company trying to attract and retain from a scarce supply of good developers, you'll need to consider how your organization rates in terms of developer experience. The pandemic and the rise of remote work amplifies the problem.
You'll easily boost your developer experience rating if you can appoint an experienced team member to be a concierge, with a hospitable attitude.
I've seen enough different workplaces to see a pattern. The most tenured team members have been molded by that company's culture. They talk about the old times, back when everyone was free wheeling and shooting from the hip. The company was young, perhaps just trying to achieve lift off.
That culture may have been right for the company at that time. However, the company has achieved escape velocity and is now in a different mode.
Some people grow with it, and some .... don't.
A person may eventually be let go, with the explanation being "you're just not a fit, you don't think strategically, you shirk process, you don't do things the *right* way, etc".
To which the person may naturally respond, "You made me this way!"
Take a business who's core competency is not software/systems, for example a manufacturing company.
This business may have started from humble beginnings, assembling parts in the garage, selling them online. Eventually, the company needs a website, then an inventory management system. They'll start with spreadsheets, using Excel to manage and track everything.
Eventually, they'll find that this doesn't scale. Next, they'll purchase "my first ERP" system. One aimed at small businesses.
Eventually, you hire a person to manage your IT needs, but you watch him closely and give him very little respect. He wasn't brought in as a business partner, but as a contractor, to do "spot work". You still haven't realized that your IT needs will be a forever endeavor, an ongoing need. As much as you want it to be spot work, where you shell out a one time fee and it's "done", you have the sinking realization that it will never be this way.
This single person who keeps IT running is buried, so you hire another. Then another. One of them eventually cobbles together a little custom piece of software to solve a specific problem, and WHAM! You are now in the software business. And you can never get out of it.
In 2011, Marc Andreesen famously declared that software is eating the world.
Five years after that, software is still eating the world.
If you want to play in this world, and have a development team embedded in your organization, you probably ought to learn how to engage with them, or hire someone who does.
But maybe you don't have to. Because in 2019, Forbes says that Software Is Eating The World, But Services Are Eating Software.
If, as an organization who never set out to be a tech company, you are frustrated by trying to be one, then just stop. It's not your core competency, it never will be, and you don't want to pay for it.
Fold up now, and just use 3rd party services. As they say, if it flies, floats, or fucks, it's cheaper to rent. If it compiles, deploys, or whines like a prima donna software developer, it's also probably cheaper to rent.
Developers have a reputation for being whiny and entitled. I'd argue that this is simple economics. The people who openly criticize management are the people who are not afraid of losing their jobs.
That is, those who can easily find another job are more vocally critical. If the market for devs was dry, and BA's and PM's were in high demand, suddenly the devs would be quiet and fearful, and BA's would be more apt to call out something as "broken".
Simple supply and demand.
See "The Dead Sea Effect",
…what happens is that the more talented and effective IT engineers are the ones most likely to leave — to evaporate, if you will. They are the ones least likely to put up with the frequent stupidities and workplace problems that plague large organizations; they are also the ones most likely to have other opportunities that they can readily move to.
What tends to remain behind is the ‘residue’ — the least talented and effective IT engineers. They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.
Adding an improvement to an existing system without shutting off the old way is a classic mistake. Mature teams and leadership make it a point to replace, not append.
If you don't have the obligation to be backward compatible, consider yourself lucky enough to be able to shut off the "old way". In fact, the "new way" should not be considered complete until the old way is completely gone.
Ask yourself, when is the last time you truly decommissioned a component of your technology stack? If users have multiple ways to achieve the same workflow, this is a smell.
This typically stems from inability to measure the usage of your product. You're afraid to take something away, because some user might scream that their cheese was moved. You should know whether or not it's in use with some basic logging and instrumentation. If you don't have that, then get it.
Code is not an asset. Code is a liability. Strive to reduce liabilities. Your users will adapt.
Let me get this straight. You're asking "senior developers" to monitor a help desk that is flooded with incoming "issues"? And you also want that developer to focus on his project? And you're mystified as to why you can't seem to
a) hit a date on these project "commitments"
b) retain any senior level dev talent
Look around your dev shop and identify anything that qualifies as a "leveling up" or productivity amplifier. Chances are that if you work for a non-tech company, in a traditional IT cost center, then few of those were initiated by management.
Automation, CI/CD, IaC, even source control. Productivity tools like screen sharing, screen recording, wiki's for knowledge sharing, rich chat clients, etc. These are all typically grass roots efforts where someone had to "fight" for it. And guess what, that person is no longer with the company, because he/she expended all of their energy and political capital to put that thing in place. That team member forced the organization to level up, against its will.
Management will say, "that guy was a pain in the ass".
Here's one flavor of how work gets defined in an IT shop. Warning, this flavor tastes like shit.
Interviewing as a candidate is precarious. There are 2 modes you typically find yourself in. There is the "I just need a job, any job" mode, and there is the "I have a job, so I can be choosy" mode.
For more junior folks, they will typically just take what's offered. Make some money. Learn some things. If it doesn't work out, move on. After you repeat this pattern a handful of times, you begin to identify some trends. You start to see that organizations are just collections of humans. Humans are flawed. Organizations are exceptional at a lower rate than individuals are.
Upon accepting a position, you generally have no idea what you're walking into. After the first month on the job, you'll have a little more clarity. You'll begin to notice some major red flags, and then there will be a voice in your head that says "would I have accepted this job if I had known about this?"
One such red flag is discovering that your manager is not in good standing with his manager. Great, I just got hired by the guy that everyone views as a stooge. Now I'm the stooge of a stooge by default. Could I have vetted this situation more thoroughly prior to taking the job? You can't exactly ask in the interview "So, who's the village idiot among the senior leadership team? Is it you?"
But there are some hints that you can glean. If the hiring manager has recently been promoted, that likely bodes well for you. He's earned some credibility in the eyes of decision makers, and he's growing a team. This sounds like a good opportunity.
On the other hand, if the hiring manager reveals to you that she has been with the company her entire 20 year career, and has just hung around as a passenger on the ride, this is a smell. For one, we all know familiarity breeds contempt. This person has likely been the fixture among a cast of characters that are rotating around her. She's perpetually upset that they brought in yet another outsider for the big role above her. She felt like it was her "turn".
This may be a controversial opinion, but staying put in one company for decades says something about a person. It says they like to be comfortable. It says that they don't like change. It may indicate that they aren't hire-able outside the company. Life is fluid. Standing still is rarely the optimal strategy.
Everyone knows that an interview is a two way street. Most people agree that the company is interviewing the candidate, and the candidate is interviewing the company. I am proposing to simplify this. As a candidate, you aren't interviewing "them". You are interviewing the individual, the hiring manager. After all, a company isn't something you can ask questions of. A person is.
A person doesn't quit her job, she quits her manager. What's the inverse of this? A person isn't hired to work for a company, she's hired to work for a manager.
Make sure you don't fall for classic traps, such as the company's name recognition, perceived stability, or overvaluing the compensation.
import json
import requests
url = 'https://api.imgur.com/3/gallery/g/memes/'
header = {'Authorization': 'Client-ID 31d84e7e126befd'} #not my real api key!
r = requests.get(url, headers=header)
{u'account_id': 11545168,
u'account_url': u'PCard',
u'animated': False,
u'bandwidth': 76530096,
u'datetime': 1403397798,
u'description': None,
u'downs': 0,
u'favorite': False,
u'height': 820,
u'id': u'1DZ31Oy',
u'is_album': False,
u'link': u'http://i.imgur.com/1DZ31Oy.png',
u'nsfw': False,
u'score': 2,
u'section': None,
u'size': 708612,
u'subtype': u'Good Fireman Greg',
u'title': u'Good Fireman Greg',
u'type': u'image/png',
u'ups': 2,
u'views': 108,
u'vote': None,
u'width': 610}
import pymongo
from pymongo import MongoClient
client = MongoClient()
db = client.imgur
db.memes.insert(r['data'])
c = db.memes.find({"subtype": "Scumbag Steve"}) #c is a db cursor
#print them to screen
for i in c:
pprint(i)