>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else?
I have worked with this person on more than one occasion and I would love to work with them again. Entire new products and verticals are often the result of such projects.
Companies have such a hard time dealing with risk. They think that the only appropriate thing is to always minimize risk. "Look, I have minimized risk at every opportunity. I am doing a great job!" That's not true all the time though. When exploring new business models or in some other situations high risk activity should be preferred.
As one of these problem people myself, it's helpful to know that this is considered bad behavior. I'm not sure it should be though...
The thought process is that many times the barrier to adopting a better technology is just the time investment. So if you're sick of working with a problematic system, but the team doesn't have the time to fix it, fixing it away from work might remove that pain point from your life. And since often these projects begin and even end as just an experiment, there's not much reason to tell the team until you have something.
It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking.
It's okay to rewrite whatever you want in off hours.
Just deploying it without consulting with anyone in place of the original production system would be a poor quality behavior.
If you think you have something, make an isolated test deployment of it for internal evaluation, and so on. No matter how the existing system sucks, at least it has some mileage in deployment and has been through some QA.
The "without telling anyone else" part is potentially the problem.
Imagine you committed time and energy to build a decent system - not perfect, but most people are ok with. You feel a sense of ownership on this system. Then one day, a coworker of your tells your manager that he has built a new system in his off time. He also made a conscious decision not to discuss the effort with you. How would that make you feel?
Yeah. As I've gotten older I've cared less and less for "my code." If the new effort is demonstrably better than the existing system, then I'm happy. Who cares who wrote the old stuff, this is better.
The problem, of course, is that often the new system is not better, it's just newer. Sure, it may be simpler and easier to understand, but is that because it is an inherently better solution, or is that because it doesn't deal with all of the the real-world conditions that the productions system has grown to support over time?
Even then re-writing is often a good thing. You can re-approach the problem domain with all the insight you've gained building the old system.
Ideally there would be good enough tests of the old system that if the new system passes the same tests, then there's high confidence that it will perform correctly in production too. That way we get the benefit of being able to refactor or reimplement entire subsystems while still having almost the same assurance as the old system.
I would suspect that the new system doesn't handle the corner cases. Its easy to say "I can rewrite reddit in a couple weeks" but there are lots of details.
> I would want to know if the new system is going to make everyone's lives easier.
If it's a large system designed by a person on their own in a corner, without interaction, without feedback on features and usability? ... it's unlikely to and I would be rightly wary.
I have however seen existing systems that have pain points that everyone complains about but no-body has the time for fixing, until someone finally takes a few days out to experiment with something different, and sometimes the results are excellent. But IMHO that's not exactly a "rewrite".
It very much depends on who that person in the corner is. I've seen junior devs waste a lot of time doing this. However, I have seen one or two examples of a senior dev solving a real pain-point that wasn't getting fixed within the system, for one reason or another.
Right; for me the determining factors between the two cases are:
1) It is a known pain point, so the problem has been discussed. Probably a lot. The pain is the reason for the code, and if there's a new tool involved, that's additional not a main reason.
2) it's usually a technical task - for example something related to faster, more reliable deployments. This means that the requirements are already well-known by the engineer, and that it probably hasn't been addressed yet as it's hard to tie to a business benefit.
3) Experience of the engineer. Senior devs are more likely to chose a good target.
Yeah, I feel like going and redesigning parts of the system that are usually other peoples' area would result in some interpersonal problems at the least.
I'm sure the dev ops people will be happy I converted our automation from Chef to Puppet, you're welcome!
> I feel like going and redesigning parts of the system that are usually other peoples' area would result in some interpersonal problems
Assuming this is done during free time and you're presenting the solution in a respectful way, then that's their problem, not yours. If you perceive this is going to happen within your team then there is already something wrong. There isn't enough trust and cooperation in working towards a common goal. Every solution should be openly presentable and scrutinizable by every team member.
If you suggest an idea, completed or not, and someone is offended by that, it's not your fault. It is a consequence of your actions. And, I'd argue it's not your responsibility to care for others' feelings to such a degree.
Some people may disagree. I don't know how they can survive. They must feel they are constantly walking on eggshells, wondering how people will react to whatever they say.
Independent of social context, this type of act is generally viewed favorably. Machiavelli claims that "nothing makes a Prince so well thought of as to undertake great enterprises and give striking proofs of his capacity." [0]
How this would go down in your particular workplace all depends on the surrounding political and social context. It could either be interpreted as "Wow, that guy is such an amazing programmer that he was able to refactor our whole legacy system in his spare time! We should definitely keep him on board and learn from this kind of work, even if we can't do a full-scale replacement." or "Wow, that guy is so self-absorbed and unwilling to cooperate with his teammates that he went home in a fit of anger and thought he could replace 10 years of work in a few weekends! What an abrasive blowhard. Let's fire him next time he gives us an excuse."
The halo effect is going to be the primary determinant here. [1] If your colleagues and superiors are predisposed to interpret your actions favorably, they'll probably do so until you give them a reason not to, and vice-versa. It takes a lot of work to maintain a good halo, and it should be considered your primary job duty if you wish to have a fulfilling career as an employee.
Humans are social animals and will evaluate everything about you, including your technical competence, by the social signals you output. Successfully managing these can get complicated in the workplace due to the competing interests of the people you come into contact with during the course of your employment.
Don't take these articles too seriously. There are a lot of reasons people consider someone a troublemaker. It's more about your 1:1 connection to other people than what category of person you are.
Yeah, in general, it's good practice to not take any article on HN seriously. Assume that the article's author and every commenter may not be experts at the thing(s) they're claiming to be. Especially when there's social aspects involved.
What aren't you doing while you are going off and being a super hero?
Are you disobeying your manager's direction? (And thereby undercutting their creditability/authority - and how does that make the manager appear to their supers/peers?)
Why can't you go to your manager and ask for permission? If not, why not?
How would you feel if your "great" rewrite is rejected - because someone else was already doing the rewrite; or because the system is going to be redesign entirely? (For example, the code will be ported from .NET to Java - and all the .NET code will be discarded)
If you haven't yet, try being a manager for a while and then see if you still think that this sort of troublemaker.
> It doesn't really seem to have much of a downside - assuming you're just presenting whatever you come up with to the team later as an option, and not going crazy and replacing production systems without asking.
That's a big if. The fear is that such a person doesn't have the judgment to not be the type of person who goes into personal-overdrive into making unfeasible changes (or, worse, into bikeshedding). It doesn't mean that such a person is a horrible person, just that opening lines of communication should be a priority, rather than letting that person put themselves in a position of difficulty.
I often would suggest rewriting apps in a different language or platform.
Management had a problem with our ActiceX based web apps not working with Macs or OS/2 machines. I offered to rewrite them to use Java instead and I was told no because Java wasn't made by Microsoft and if I wrote anything in Java I'd be fired.
Another job I aaw that VB 6.0 and Windows 98 was too slow and I offered to rewrite the app in C ir C++ and use GNU/Linux to make it faster. Same problem not Microsoft so management didn't want me to rewrite it.
Replacing a home brew ORM in an application of any scale is a massive time and bug investment. It will be tied into every single aspect of everything, and even into the build and database deploy processes. It often has its own classes with their own internal behaviour which get passed around raw - so you can't just upgrade one price of code and test and move on, you'll have to rewrite the entire product at once.
Having seen it done I can understand very easily how someone could not just remove it.
I have no choice but to replace it as the databases it accesses are changing. But as you said, it is a massive sink of time to change a core part of your system that some many other parts depend on.
Sometimes that behavior arises because the person is bored, or they feel their skills aren't being utilized, or they feel like their concerns about an existing system are being minimized.
Yea, those people need to learn to work on their own stuff. I do so much of my own/oss work at work and am surprised at how everyone has always said I'm doing great and my stuff is always out faster and more tested than everyone else.
..expectations are low, and there's value in keeping it that way! :)
(all my favoruite stuff has been stuff I've worked on for myself, that doesn't earn any money. I find almost all of it more worthwhile than any of the technical entrenched garbage I've written in the corporate world for the past decade of my life)
...which can have wide-reaching implications if you release work product produced during work hours as OSS. While your company may seem like they don't care now, that can always change. Copyrights last a long time. Please don't risk the well-being of an open-source project by surreptitiously submitting code that your company owns.
> That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else?
I had a boss who came back from vacation that was so threatened by the automated testing harness myself and another coworker created, that she rewrote the entire system herself.
I've seen this. Automated a bunch in well documented PowerShell modules which I trained staff on and was all taken out when I left.
Because the PM said, "If it can be in a script it should be in C#!"
Of course the C# programmers didn't like being taken off of productive work to build infrastructure tooling which was working perfectly well in PowerShell where it belonged. So they quit. So did the remaining DBA staff. All of them.
So the company told their customers this feature was broken and would not be updated in the foreseeable future. That was a year or two ago.
They could just run the script. But they refuse to on principle. So they suffer and the customers suffer. Companies are great!
She talks about risk/reward and acknowledging the benefit new tech can bring to an organization. Minimizing risk doesn't mean no risk. High risk regardless of reward should not be preferred; risk/reward discussions and reasonable decisions should be preferred.
>That guy who decides to rewrite an entire system in his off-hours in a new language without telling anyone else?
Damn! I was thinking about doing that right today for a subsystem we use at work... trying to gauge its performance in the new language and eventually "sell" it to replace the existing one...
Its been a bit over generalized -- sometimes its a nice surprise. If that subsystem at work is a source of constant pain and annoyance, it may be welcomed with open arms. I think the case she's intending to illustrate is something like someone going rogue and re-writing a working system. In another language. Maybe a language that nobody really wants to use. They could have at least discussed it with their colleagues. Two (mostly) different scenarios!
A couple of instances of this come to mind. One is Paul Graham's story of Trevor Blackwell rewriting the viaweb code in Smalltalk. Paul said No. Reddit was written originally in Lisp, but they rewrote it in Python. That stuck.
I think that attributing resistance to the off-hours rewrite just because of minimizing risk is oversimplifying the issue.
I think you're misinterpreting it. She's saying a person who rewrites (implied: and implements) a core process without informing other developers or product teams.
She notes that she has a tendency to require that the solution work her way when coding.
I wonder if she realizes she's doing the same when working with people's problems? Almost all of those solutions end with, "do it my way or get out."
Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.
For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.
>For someone who wrote an entire blogpost about the benefits of troublemakers and how to integrate them, she doesn't seem very willing to actually work with them, just to make them work for her.
That's kind of the point. You don't want to be working with someone who can't work with other people. If you're a "troublemaker" and refuse to change and adapt to the way the company you work for does things, go ahead and found your own and do it your way, and see if others are willing to work for you in the long term, or find another company with the culture you're after. When it comes to tech there's plenty of companies out there who hire for different personalities and abilities.
I think there's often a way to use understand what motivates the "trouble-maker" (I dislike that label here) and use it effectively that doesn't take a lot of effort, just getting to know the person and letting them get to know your position.
Yeah, because nobody would want someone like Alan Turing at their company.
The whole "everyone must be a team player" thing is such crap. I will gladly take a one man army with the resolve to deliver above all else over a team of mediocre players who take 4 times as long and waste more time arguing in meetings than it would take to just bust the thing out twice.
Effective teams are great too, but if you can't figure out how to use the other type, it really is your loss.
>You don't want to be working with someone who can't work with other people.
That describes me pretty well, and those with whom I work love me. They just keep me in my little box, leave me alone and let me do my work. But they are also a grown-up company that doesn't make people wear 27 hats. PMs do their job, Infrastructure does theirs, Client Support does theirs, etc. Not every job has the same requirements as every other job.
> Not a collaborative coder? No room for you here. Not a people person? No room for you here. Want to use the latest technologies? No room for you here.
That's corporate life in America. No room for individualism. But I've heard it's even worse in Japan, so there's that...
Of course there's room for individualism. But if you're going to make the rest of your coworkers lives a misery, you'll find that you'll be expressing your individualism in your own one-person startup.
How is doing something like re-writing a system in your off hours making your co-workers miserable? I mean sure, if you then proceed to bug your boss every day to adopt the new system after he carefully reviewed it and rejected it, I'm with you.
And she lists several "harmful" practices like this.
In short, taking initiative? Nope, we don't like that here in corporate America. Doing what you're told and minimize risk. Don't actually try to make us money or anything.
They're not. Corporate America is pretty risk averse. 90% of any top 500 would freak out about that. Imagine a guy in the legal department rewriting the Eula in his spare time, or the hr director rolling in with a new employee handbook.
Software is a little special, because you can still kinda get away with that.
Eh, Idk if it's that bad in US; if anything the other countries are worse. If you want to scratch that itch find a startup that uses latest and greatest stack.
Agreed. Was hoping for better insight but not really getting much.
Currently dealing with a fellow that exhibits all four of the documented traits plus a general unwillingness to document anything. Kind of unsalvageable at this point... =(
The article misses some key things I would throw out there, here's to hoping they come to value with you.
1. Bake rules into your workflow. For instance, enforce daily or semi-daily standups. Make git commits a portion of things in those - so everybody has to say what they've done in git commits (obviously, this isn't 100% of things). Other coders on the team will be annoyed by the person who isn't committing code daily, so this will mean that coder is admitting not to you, but to them, they're playing by different rules.
2. Force them to write design docs for implementing new technologies, before they're implemented. Then write a retrospective about how things went over, a week or two after the project is launched (things that were unexpected?). This can serve as documentation, but adds a bit more clarity to the overhead that comes with these changes, which is easy to miss when you're in the thick of things. Perhaps it's all they need to understand what kind of complexity they're adding (or what kind of simplicity you're not giving them credit for).
> Almost all of those solutions end with, "do it my way or get out."
Agreed. My style is to contribute to creating the goals of the team in addition to the projects. She'd probably call me a trouble maker haha! And I'd be proud to be one. Aren't computer programmers supposed to be troublemakers? We're hacking the system ... ;-)
Working effectively with other people is definitely a skill. Some people have it from birth and some have to learn it. One blog post isn't going to solve everyone's problems but it is interesting to hear her experience.
I would rather work for someone that lays out the problem to be solved, documents the constraints, and unleashes smart people.
I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.
> I have been in the position where the VP of IT wants to have his cake and eat it too: VP salary while micromanaging variable names that the dev team uses so that he can relive his salad days as a tech lead.
While that may be the reason in that particular case, it seems to me the more common problem for micromanagement isn't a desire to relive one's days in a position lower on the org chart, its simply lacking the skills to operate at one's new level. Or, I guess, a corollary to the Peter Principle: people tend to work at their level of competence, despite being promoted to their level of incompetence.
True. But most things the leader cares about are things we as developers don't care about. E.g. he wants people to work together because fights are unefficient (we usually don't care if we are not involved directly), he wants certain processes to be applied so that departments we don't think about also get the data they need to do their jobs, he wants to be able to answer questions in the meetings he goes so we don't have to.
So yeah, the technical problems should be open to solve for me as I and my team think. But there are a lot of things my manager should define for me and care about even if I don't. That's why he's part of my team.
Managers I respect would more accurately be described as saying "join the team or get out".
My favorite managers are coordinators and facilitators. They listen to everyone's input, above and below them, and stear the ship towards success. They gauge input commensurate with the experience and knowledge of each person from whom it came. They make decisions with special sauce that can't really be boiled down to words. They're transparent, communicative, thoughtful, available and appreciative.
If the manager has heavy experience and success, it may sound like he's saying "do this my way or get out". For example, Steve Jobs felt he had great taste, and many people felt he was a jerk.
He obviously received input from a huge number of people and couldn't have made Apple successful alone. He discusses how Apple recovered in the late 90s at D5 in 2007 [0]. The NeXT brainstorms are also interesting to watch [1]
Wow fuck everything about this, it sounds like extreme micro management.
The premise here is a) do exactly what you're told and b) in exactly the way we tell you or c) you are mentally ill.
Now I'll agree that some of it is plain toxic. You can't deploy whatever you want to production. But that's one line from an entire article of benign behaviour.
You're REALLY going to crush Mr/Mrs Nostalgia? WHY WOULD YOU BOTHER. If someone saying things were better two years ago is going to crush your organisation then FFS you have bigger problems on your hands.
I'd also like to put forward that if you're a hermit you either may just take pride in your work (a carpenter doesn't go parading around a half built table) or are STILL working in a toxic company (not just came from one so its your fault).
If they're doing the job then for fucks sake let people be rather than trying to invent a job description for yourself which involves "fixing" normal people.
There's a reason people are quitting when faced with this "mentoring" and it's not because they're burnt out.
Sigh. Yet more unsubstantiated psychobabble pablum.
Managing people is hard. Mmmmmkay?
My ability to manage is a function of how creatively and effectively I can be in aligning the company's goals with the worker's goals. It won't be 100% (that's why it's called a "job" and we pay people), but most managers barely even try. Funny how "troublemakers" seem to get in line when you actually manage to understand what motivates them.
If a manager can't do that, either A) the manager needs to be replaced or B) the employee needs to be replaced.
The problem is that we don't fire/demote managers nearly often enough, and we fire employees far too often.
Did you read the article? A good chunk of it was about understanding the trouble makers to see what motivates them and aligning both the goals of the employee and the company.
Nice article. From my experience the biggest troublemakers are often in management two layers or more above and have no discipline in making changes or throwing new ideas into the pipeline.
ha! Very same experience here, too. I was just working at a place where one of the designer-founders redesigned a page to look one way. Then three months later, he redesigned it again, to look back the old way. He actually put these into the pipeline, assigned it to different engineers, and there was no reasoning over choosing one way or the other. Both designs had the same functionality and the same glaring flaws. He just kept wavering and wouldn't even consider doing any user testing or A/B testing on it. Glad I don't work there anymore.
> He just kept wavering and wouldn't even consider doing any user testing or A/B testing on it.
That's why it's essential to pre-commit to a culture of testing everything. It's by far the best weapon you have against a founder with a terrible idea that they won't drop.
Funny thing was this place did espouse "test everything" except it came in the form of our Product leads "test only the things I don't agree with." Which of course meant we were using all of our testing budget on dumb things.
I would hate to work for this lady. The fact she labels these archetypes, which are questionable in the first place, as "troublemakers" really makes it clear what she thinks. She's better than her engineers, they're lucky to work for her, and if they're not careful, she'll fire them.
That does not sound like a fun work environment. Not that I'm trying to be a troublemaker... (Please don't put me in timeout!)
I didn't get the feeling that she thought she was better than her engineers.
Regardless of that, each of these archetypes presents real difficulties to a team that has to deal with them. A hermit can cause massive troubles for a company if they are doing critical work. In the case that someone is prolematic to the team, it's better to solve the problem than to lose the person, and that's what she tried to do.
> I remember several instances when it took a few deep breaths to keep me from kicking him out. But today he leads a team and triages the troublemakers he once was. Sometimes when you save a troublemaker, you’re saving a team they’re not yet on.
She saved the troublemaker by taking a few deep breaths, not the team. She blames the troublemaker for his bad behavior, and takes credit for his good behavior.
She does not acknowledge efforts made by other team members, and barely acknowledges the individual himself for the adjustments he made.
She could've written "Sometimes when you are patient with a troublemaker, you're helping to save a team they're not yet on."
We each make our own choices and face the consequences, good or bad. There is room for guides to help people understand consequences. Mentors and managers do not make choices for individuals. Ultimately, each choice is our own.
I think she meant it as written. It sounds like she helped refocus the "troublemaker's" energy, language, mannerisms in a way that helped him be a positive contributor rather than someone who was resented by the rest of the team
I got to disagree with the whole continuity over ingenuity trope. It's how I can continue to remain modern as an engineer, and if done correctly, leads to vast gains in cognitive complexity by delegating concerns to newfangled tools that handle it better. Sure, it's a bit less stable, but this is how we keep the industry moving quickly, and I hope managers see it more in terms of trading technical debts than a stubborn "oh great, you want to introduce another new tool!?"
Right, because your growth as an engineer trumps the company's concerns over having a stable code base.
I can't count the number of times I've had to give some variation on this speech to junior engineers of one stripe or another: The company does not exist to give you cool things to hack on. The company exists to provide a product or service to its customers, from whom it collects revenue, in order to repay its investors, pay its employees and suppliers, and hopefully also make a profit. To the extent playing with cool, new, whiz-bang furthers those goals, it will happen, but whiz-bang is neither necessary nor sufficient for those goals. In fact, whiz-bang for its own sake can often be inimical to those goals.
I don't agree with the comment you replied to for a variety of other reasons but your reply is really out there. You could say exactly the same thing about any job benefits including a salary. Whether it's "essential" to the company on paper doesn't mean much.
We're blessed to work in an area where it's possible to grow your own skills while staying within the same company. If a company can provide this to its engineers, it's a win-win - employee skills improves, they want to stay longer, etc. And let's not forget humans, not AIs, are at the helm of those companies.
An employer is legally required to pay you for your time.
They aren't anything whatsoever to let you build things that they're somehow going to depend on using NewHotness-0.1.3.
EDIT: Look, I'm not saying growth and exploration are bad things. I'd never have learned the tools and technologies that have fed me for years now, or been able to expand those skills in ways that have made me tremendously valuable to the people who've decided to pay me nontrivial sums of money in exchange for my knowledge, skills, and time, if I hadn't been, as you say, "blessed" with opportunities to try new things.
But there's a difference between acting like you're blessed, which to my mind entails exploration with respect for the needs of the folks who are paying you to explore, and gratitude for the opportunity to do so — and acting like you're entitled, which ignores those things, and treats it as an exercise in résumé-padding.
Yes? That's not really relevant. You can just as well say "The company does not exist to give you money. It exists to provide a product to its customers."
When you're getting a salary you're standing in the way of the company making that money they're giving you. It's very counter-productive (and illegal, as you mentioned), but if you find this silly maybe you understand why I find your original reply silly.
But the company doesn't exist to give you money. That you, specifically, get paid for your specific services is incidental to the company's purpose, which is, indeed, serving the needs of its customers. Your job is to facilitate that, not to play with cool new tech.
You aren't "standing in the way" of them making the money they pay you; they're making a choice, with every paycheck, that your time is worth more to them than what they're spending to keep you there. You upset that balance by introducing instability into the stack because it's new and shiny at the ultimate risk of making that exchange no longer worthwhile.
>Right, because your growth as an engineer trumps the company's concerns over having a stable code base.
When a good engineer can easily move to dozens of other companies, yes, it does. If I felt like my growth had stagnated and my employer wasn't willing to work with me, I'd move on.
And I'd submit that a "good" engineer is, by definition, the kind that understands when it's appropriate to use new technologies, and when it's not — and "Look, shiny!" isn't, IMO, a good enough reason.
And pushing — let alone threatening to move on — to use new tools when they aren't appropriate? Please, go be someone else's problem.
Here's the problem: Everything, no exceptions, starts out as "Look, shiny!". Usually, you need to play with it to find out if you even have a use case to justify spending the resources to do a formal evaluation. Reading the docs is a poor substitute for deploying it.
Now what the article talks about is "shiny!" being pushed into production. No, no no no no. Never do that. There's no excuse for just dropping new untested shit into prod where customers can trip over errors - I think everyone can agree?
But if hypothetical you is preventing your hypothetical engineers from indulging their curiosity and trying out new things to see if there's even a business case to be made for production use ("But there's no time" counts here), you're hamstringing the engineers and hamstringing your business.
Yeah, this is a good summary. There should be room for experimentation in isolated, non-production environments if the engineer in question is trusted and can propose a hypothesis better than "I think this will make my resume better". That stuff shouldn't be rushed out to prod without thorough vetting both internally and externally, which, much to the dismay of junior engineers (and not-so-junior engineers with bad judgment), often means letting a tool age a little bit before you bet the company on its stability. Unless the tool truly revolutionizes your particular line of business, and let me pre-emptively state that there's a 99.99% chance that it doesn't even if you think it does, there is no harm in letting other people be the guinea pigs.
Violent agreements are lovely when they're sorted out by the market: at the moment, the best engineering talent I know would not be caught dead working on (just as an example) PHP.
There's simply no need to let your skills and salary stagnate when you can get paid more for working with the state of the art elsewhere.
Demand is simply too high, and like anything, there's tradeoffs: you can get anyone to do anything for enough money. But "great talent," "cheap," "low autonomy," "fossilized tools," will require some compromise.
That's your choice. But as a professional, you should do the best for your employer or customer while they are paying your salary, and that means adopting the right tools for the job, not your resume.
> The company does not exist to give you cool things to hack on.
Until you start losing employees to competitors who do offer cool technologies to work on. Your patronizing tone about how "junior" engineers just don't understand business is unwarranted. ALL engineers, not just "juniors", need to stay relevant in their field. Some of us actually enjoy what we do, too. Keep using antiquated technologies and watch your talent pool dwindle and your product gradually become obsolete.
I think a lot of engineers would consider it a selling point if the company gave them an opportunity to explore new technologies, so long as they are working on business goals in parallel.
I'll just consider myself happy I don't work with a manager like you, then.
The company doesn't exist for me to hack on cool new things. Of course not. But what you fail to understand is that I'm a very intelligent person who is not planning on spending the rest of my life doing shitty simple e-commerce UIs, or whatever it is that you do. It's easy to think nothing but the goals of the company matter, especially if you're an awful founder, but the world just doesn't work that way. We all need to move on when the company likely dies, and I don't want four years of "I had no choice but to work with crap" on my resume when this happens, just because I had an asshole boss who hated other people who did smart things around him.
Your enthusiasm for new tools and the energy with which you embrace change is great. Don't lose that.
But it's no fun to try to use something, and you can't because someone moved fast and broke things. It's even less fun when your customers are calling you because your site is down, and all you can say is "It's a problem with the platform." Before long, you get to choose between the platform you're paying for, and the customers who are paying you.
All these comments are one-sided. Note that gravity13 said "if done correctly"
There are pros and cons to adding new tools. Each situation is different and would ideally be decided by all the effected team members. It depends on the team, existing tools, product, whether it is released yet or not, and a myriad of other things.
An engineer could install whatever he likes on his own machine or VM in his free time, if he has any. If other engineers have a problem with that, then like gay marriage and abortion, that is their problem. Similarly, if an engineer installs software willy-nilly on a production machine that has active users, I think we can all see how that is unreasonable. So the debate comes down to the in-between grey areas. Without being in the moment, none of us can comment on it towards any real conclusion.
It's important to realize this is written from the perspective of an employer. For an employer, it is much more important that someone can easily take up the reins if something happens to you. From a companies perspective, it is best if their employees are easily replaceable. Employees that can't easily be replaced are expensive. They have the ability to command a higher salary and can force companies to do things they wouldn't otherwise do.
From the perspective of an employee, the company is forcing you to stagnate and become someone that is easily replaced. I don't blame anyone for being insulted by this. The company is advancing their own interests at the cost of their own.
Nobody enjoys being forced to do something. So while an employee forced to work in a certain way can be expected to be bent out of shape, so can an employer whose hand has been forced by an employee. The adage 'shit flows downhill' is true, and the intractable employee will soon find themselves swimming in it.
A company may decide to cut their losses early if you are actively making your position harder to fill. From their perspective, the longer they wait, the more deeply entrenched you become. Companies value reliability. They want someone they can count on. The same goes for people. If your manager doesn't feel they can trust you, if they are consistently afraid that you will embarrass them, then you are a liability to them. If you aren't outright fired, you will be kept on a very short leash.
There are a lot of benefits to toeing the company line, insulting as it may seem. Should you find yourself in the good graces of your manager (and by extension, the good graces of the company), you will enjoy a remarkable amount of autonomy. By being dependable (if not predictable), you gain job security and autonomy. You will find your suggestions are taken more seriously, as nobody is left to wonder what trick you have up your sleeve.
I totally understand where you are coming from. I am always looking for better tools for the job at hand. Companies move slow, and technology moves fast, and it's easy to be left behind if you move at the speed of the company. Ingratiating yourself to your company takes time too. It could be years before you get to use a new technology, at which point an even better tool shows up.
The company has the upper hand in this situation. Changes probably won't come quickly. If you find yourself in a position where you aren't happy with the way you are allowed to do your job, oftentimes the easiest way to solve the problem is to find a new job.
Employees that can't easily be replaced are expensive. They have the ability to command a higher salary and can force companies to do things they wouldn't otherwise do.
A truck number of 1 is a bad deal all the way around unless the employee in question enjoys going without a vacation.
Reasonable arguments. But what's the connection with the article or a previous comment?
Also I've found that most managers know they should keep their team replacable, but also efficient. And they often end up treating long term replacability for short term efficiency gains, again and again and again. So while it should be a real issue it is less often than we coders worry.
This is a gold mine, I'm so glad to have found this article, thank you for sharing!
I definitely evolved from "The Hermit" into what I am currently, some form of "Smartest in the Room"(I don't think I'm smarter, I just tend to think the way I came up with is best).
Being a developer is a process! I'm incredibly interested when we stop pretending that everyone's a "rockstar" or whatever, and start talking about the problems that come up, and how to work through them. I'm only just now coming to the realization within the last few weeks that I need to be more open to alternative and intermediate solutions that aren't perfect, but solve the problem for the time being.
> I remember several instances when it took a few deep breaths to keep me from kicking him out. But today he leads a team and triages the troublemakers he once was. Sometimes when you save a troublemaker, you’re saving a team they’re not yet on.
What a saint. Seriously, it always felt funny to me when a team member was let go at the behest of one or a few individuals.
Anyway, the way she says this leads me to believe she thinks she is more important than other people.
Well that's silly. All managers do not feel that way, and the salary sure isn't higher in many cases unless you're nearing the top of the organization.
Being a manager is simply a different job function.
This is where I feel like the title "project manager" ought to be reconsidered, perhaps to "project secretary." That way, it's a bit more clear there's less of a hierarchy and more of a duty.
Good managers don't think they're more important than other people. In fact, the best managers realize that the happiness and success of the people they manage trumps their own desires.
> In fact, the best managers realize that the happiness and success of the people they manage trumps their own desires.
I'd say everyone's happiness is equally important. I agree that managers are often in a more secure position and can afford sacrificing some of their desires. Generally speaking, they should not need to become unhappy in order to make their own employees happy. Excepting, of course, a CEO who's earned his due and is now taking a $1 salary, and the cash-strapped entrepeneur who's trying to hold his fledgling business afloat and expects future returns.
On the other hand, the way she said it leads me to believe she thinks her team is more important than an individual contributor and that, while it's possible to benefit in the short term from extreme talents who are also socially or culturally problematic, reforming them to remove that problem is a win-win for everybody.
It's not a bad thing to assume nuance when you read intent.
> she thinks her team is more important than an individual
Both scenarios are possible. A manager could say that all other team members are equally important while also implying that she or he is more important.
She saved the troublemaker by taking a few deep breaths, not the team. She blames the troublemaker for his bad behavior, and takes credit for his good behavior:
> But today he leads a team and triages the troublemakers he once was. Sometimes when you save a troublemaker, you're saving a team they're not yet on.
I understand the need for consultants and managers to brand themselves. She goes a little overboard. She does not acknowledge efforts made by other team members, and barely acknowledges the individual himself for the adjustments he made.
You write, "reforming them to remove that problem is a win-win for everybody". It sounds like you also feel it's possible for one individual to wholly change another.
If that is your meaning, I respectfully disagree. We each make our own choices and face the consequences, good or bad. There is room for guides to help people understand consequences. Mentors and managers do not make choices for individuals. Ultimately, each choice is our own.
There's a big difference IMO between what she wrote and a more realistic rewrite: "Sometimes when you are patient with a troublemaker, you're helping to save a team they're not yet on."
Having worked in several divergent fields as a Proposal Writer (aka Team Leader with Zero Authority) - health care, finance, and insurance - nearly none of these archetypes are exclusive to engineering or the tech sector. I think they are reasonable break-downs of classification as presented (Hermit, Nostalgia, Trend Chaser, and Smarty) which can be useful to consider in pretty much any professional, team environment. This article could be helpful to get a more relaxed, casual perspective of employees that can be frustrating.
I've often joked that working in a fast paced, multi-deadline Proposal gig, it's like herding cats. Each team might have one or more of these troublemakers - or, worse yet, be the 'name / lead person' running the opportunity - and so learning techniques to work through the challenges became second nature. Always was a fan of Kevin Mitnick, and his guides on social engineering security can be resonably applied in manipulating team members for great good. YMMV.
About the hermit: Why isn't the first assumption to look into the company's own culture? I mean you can work on trust as much as you want. If there is no reason to have trust in the team the tactic will fail.
This is a good article and reminds me of myself as a young trouble maker in my first major job after graduating. I think I was really pretty hard to work with. Now, not so much. My personal arc reminds me of growing up where my parents, particularly my father, was quite strict. Once I had children of my own, I often heard myself using my father's strict voice quite often.
Her career also reminds me of Gerald M. Weinberg who started out as a computer programmer turned consultant. He eventually realized that many of the problems he was brought in to solve weren't strictly technological, and ended up debugging teams, using her terminology, and that became his career.
"For the last 20 years, Blount has led technical teams at a range of companies."
LinkedIn says she was an IC until 2002, and then from 2002 through 2006 she was a "software design/project management" which is also an IC role. So really she's been leading technical teams for at most 10 years, which is not someone I would suggest anyone turn to for sage and experienced advice.
The way in which this site keeps bringing up a layer to get me to sign up for something everytime I go away from reading what is an interesting article is infuriating.
Both Kenji's words and the generalizations and labels used in the article are not true representations of people. People don't fall into nice neat boxes. Every programmer and gamer does not hate women, and every feminist does not tell other people what to do.
I find both of these generalizations useless and misleading, although the article is more interesting because it provides actual details and gives the reader a chance to take away what he/she chooses. Kenji's comment is simply inflammatory.
You're denigrating her because of her hairstyle and perceived political leanings? How is that relevant to the content of the article? You don't think she could possibly have relevant experience in spite of these things? Your comment is utterly tactless.
I have worked with this person on more than one occasion and I would love to work with them again. Entire new products and verticals are often the result of such projects.
Companies have such a hard time dealing with risk. They think that the only appropriate thing is to always minimize risk. "Look, I have minimized risk at every opportunity. I am doing a great job!" That's not true all the time though. When exploring new business models or in some other situations high risk activity should be preferred.