Are you a rockstar developer, or do you want to be? Is being a rockstar a good idea or a bad one? What does it take to do great work in software development, does it take rockstar developers or just good habits? The idea of the developer rockstar is mostly a creation of the recruitment industry to appeal to the best developers, but in reality, this is not a great model for delivering great software and comes with lots of problems. It also goes against what Google and others have found about what it takes to create great software.
In this episode Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering” unpicks the idea of “Rockstar developers” and compares them to how effective, high-performing, teams work.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
🔗 LINKS:
• www.hanselman.com/blog/the-my...
• Belbin ➡️ en.wikipedia.org/wiki/Meredit...
• Belbin Team Roles ➡️ www.belbin.com/about/belbin-t...
• Project Aristotle & Belbin ➡️ www.belbin.com/media/2565/bel...
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ oc.to/Dave-Farley
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
I'm not a rock star. I'm more of a prog-rock star. I'm technically sound, but probably too complicated and most people don't listen to me.
🤣🤣🤣I am pretty sure that I am in that category too 😎
I remember another classification scheme apparently taken from a German general. He said that there are four types of officers: the clever and lazy, the clever and industrious, the stupid and lazy, and the stupid and industrious. The clever and lazy you make Chief of Staff, because he will not try to do everybody else’s work, and will always have time to think. The clever and industrious you make his deputy. The stupid and lazy you put into a line battalion and kick him into doing a job of work. The stupid and industrious you must get rid of at once because he is a national danger.
This classification is so much better than calling someone rockstar.
Clever and stupid is quite a simplification... imagine combining it with Gregorc scale. Depending on what personally, type of thinking you expect for job the clever can seem stupid. Like imagine an artist in stationary work at factory or an Am. Indian on a cotton farm.
In my experience, being labeled a rockstar means 2 things - they don't trust the rest of their team, and you will never be allowed to take a vacation. If I was gone for even a single day, I would get a phone call. That gets old very fast. I have turned down jobs because the hiring manager used the term rockstar, even though in one case I knew the manager and already had a certain amount of trust. Just using the word points to serious flaws in their thinking and casts doubt on the team dynamic.
Just increase your hourley rate so its worth it, eventually you will be around with other competent people lul
Well said! Rockstar is a label the lazy give to those who they expect to do their job for them. Nobody ever calls THEMSELF a Rockstar, unless we are counting what I put in my CV!
The definition of Rockstar developer shouldn't be if they "10x" their own code, it should be if they "10x" everyone around them code by mentoring imo.
+1 to the most overlooked comment. Mentors are force multipliers.
GOTO 2017 • Beyond Developer • Dan North 29m55s
Well said.
Exactly. If they can walk out and take vacation and the team around them.handles things well, that shows they dont hord knowledge or skills and instead help share it so everyone improves.
You can't mentor IQ. You also can't "mentor" several years of intense learning. You can mentor attitudes and not much else. The only way you can get 10x out of that is if the mentoring causes the worst devs to disrupt everybody else less.
My personal analogy with dev teams is that they should be formed like cycling teams, the stronger developers help reduce the drag of complexity for other devs when needed, and at any point one of the other developers should be able to take centre stage. Support each other and the reward is greater than any individual skill set. Even after 20 years in technology I learn more from the inquisitive team member that is new to software. Keep sharing and learning on the “continuous” road to “delivering” greater skills to yourself and others.
First job I ever had, there were the 2 "rockstars" on the team. The view was that they were given the difficult projects, and they managed to deliver. No one actually realised that the difficult projects were problems because these guys were on them. One refused to be managed by the team lead, so was managed by the IT director. Big ego. They worked on a large customisation for a client, and it was a mess / disaster. Way pass the deadline, really unhappy client. But the "rockstars" were needed for the next difficult project, and all the money had been spent. They moved off and I got the project instead, the most junior person on the team. Ended up throwing out the majority of what they had written. Clients came in for a testing session, I met them at before lunch, and they were in a foul mood, but my Project Manager was happy. Turned out they hadn't hit a single problem all morning, so the clients hadn't had a cigarette break all morning and bad mood with nicotine withdrawal. Anyway, project completed and rolled out. Client was happy, and the system paid for it's self and then some at the next Budget Speech. Having my 1 year review (at 15 months) with the IT director. He mused how this "problem project" stopped being a problem after I took it on, and was trying to come up with reasons other than the "rockstars" cause the problems because they weren't any good.
So, basically you are the new Rockstar of the team ?
@@alefratat4018 Nope, the IT director was unable to grasp what a dysfunctional department he'd created. I knew if I wanted to grow I'd have to do it elsewhere. I was in my next job 6 weeks later. Did actually run into the most dysfunctional of the pair about 8 years later in Hong Kong. He was a client's senior programmer. I'd been requested by our Malaysian office to help out as I'd built up a strong rep for SQL Server development. As soon as "Rockstar" found out I was on the project he tried to have me kicked off for apparently knowing nothing about SQL Server. We'd had 0 contact with each other for 8 years.
I work at a company where 2 very intelligent engineers were fighting and shouting at each other on a meeting just because they have different takes on how to go with the task. Man, I'd rather work with average people who work well together than very intelligent people who tend to butt heads all the time because they both think they're better than the other.
I did NOT expect a video from a channel named "Continuous Delivery" to deliver such an emotional gut punch at the end: "If you really care about doing a great job and you are always the smartest person in the room, rather than buying sunglasses and Jack Daniels I suggest you find a better room." That so hit me hard right where I needed it. Thank you! Now off to find a better room.
Good luck!
I had a terrible experience with so called Rockstar developer. We both were working on a same project and I was a junior developer. It was my first job after completing my degree. Initially I thought I am dumb and I have to learn so many things, because always he was the one who would bring ideas to the table, and would go and write tons of code alone, without collaboration and without letting anyone one whats his approach is. Next day, team would praise him and celebrate his achievements in a slack channel. And, I would just sit there looking at his code and try to understand what he has done. No doubt, he did fantastic job writing code but he never discussed his approaches beforehand. then how am I going to contribute. Eventually Covid came and I was released. Now I understand it was not me. It has been 3 years and I am writing great software after that. Of course with the team.
That sucks. When dealing with people like this is good to be VERY explicit in your intentions to contribute and understand the process. Usually they are so deep in their own ass that they don't think about other people's needs on their team. Either they will recognize their mistake and try to include you more or at least try to explain more things because it makes them feel smart, either way you get something out of it.
Dude are you worked with me 🤣
@@adnandzindosoda Lol... Are you one of those rockstar developer?
Well i'm one such developer and i can tell you we don't usually mean anything bad by it, in my case i always suffered from long term imposter syndrome and so i feel the need to constantly overachieve in order to be at peace with myself, but i don't keep information from other people, and go out of my way to welcome questions from anyone no matter how stupid they might think the questions are. Now you also brought up an important point, the "rockstar" is less likely to get shifted or released unwillingly than a "coder of the line" might be, because you're more replaceable than the rockstar, that also lends personal validity to people wanting to be "rockstars" to feel that extra job security and stability though this comes at major personal cost and usually rockstars are brought down through just sheer burn out over time, you can burn very bright for a short time but you'll eventually just burn yourself out. Happened to me a good 3 times, but i can't really change, though in my case the team still functions when i'm not there, i just contribute a lot when i am, and that fulfils everyone's needs, i'm happy and comfortable and at peace, the juniors always learn something from me and are free to pick my brain whenever and i enjoy teaching them stuff i learn, and the rest of the team is confident enough without me that i can go on vacation or sick leave without expecting annoying phone calls. Sounds to me like the problem was not his rockstar mindset but rather that he just didn't communicate so he wasn't much of a team player, not necessarily the same imo, you can be a rockstar and a team player simultaneously, especially as you grow older and realise not being able to take a week off work SUCKS lol
The "rockstar" programmer, that goes off and creates amazing code completely solo, but in the process, blocks *everyone* in the team, whilst they wait for that code to be delivered. In the standup, it's like "Yeah, I'm almost done with this, just adding some tests" ... and the next day, another excuse ... and the next and the next. Management are too scared to try to bring them in line in terms of communication, in terms of stopping them from blocking the entire team from progressing. When the code is finally delivered, the rest of the team having had very little input, have to now try and figure out exactly what the "rockstar" has written. Often, it can indeed be amazing code - it can indeed solve many complex problems - but nobody else was around for the ride, nobody else _learned_ anything. More importantly, it blocked the progress of many aspects of the solution - it actually, overall, held the team back. The Lone Wolf Rockstar programmer is really of no use to a team, regardless of how good their output may eventually be. They are leveraging their skills for reasons of power - to hold sway over others. I've seen this many times, it isn't nice.
I've had to deal with "rockstar" developers making it impossible to do my job before. I've moved at a pace that the team can't keep up before. I've paced myself to match the teams pace before. Seems like the greenest developers can keep up so long as the team is being a team.
Sounds like you are confusing "rockstar" with "lone wolf"
@@justsomeguy8385 Sounds like you didn't watch the video.
I am one of these guys.
This is a stupid mentality that undervalues competence. You start with the term rockstar and then start conceptualzing it as if a rockstar is also a lone wolf. This is very far from the truth in development teams. "rockstar programmer" fundametally is simply a hyper competent programmer with high level of both technical and macro skills for project development. It may be certainly be cases were anyone with a not enough competence level won't add to the team with these people around. No matter, TEAMS , succesful teams are always made by competent people. REAL TEAMS are hard to make happen, most often you dont work on a team but with group of people. When you already have A TEAM is because you are already working with competent individuals. A hyper competent individual "blocking" other peoples work only truly happens when the different in skills are waaay too massive, in that case the issue to fix is bringing performant individuals to the team. You are thinking backwards
This absolutely mirrors my experience when I’ve worked on great teams. I’ve even had a team improve when the “best” developer left. He wasn’t a good team player.
Then who called him the "best" developer by what standards? Are u going to toilet as team or is there anything you can do on your own?
@@MrGerdbrecht he probably just means they were technically the most capable yet socially the most inept. Him leaving made the morale and overall team dynamic improve . Probably what Bryan meant here
@@MrGerdbrecht son, I was the team lead. No, we delivered better after he left. I can tell you struggle though. 👍
To what are you saying "No" to? And why do you call him "son"?
Software is such a strange field, at least in part because programming tends to attract people with mildly (or sometimes thoroughly) antisocial personality traits. There’s so, so much to be said for just trying to go out of your way a bit to be generous with your coworkers, and give them the benefit of the doubt, but this is often just too much to mask from many folks in this sphere. Definitely love what Farley is saying here about standout teams often coming from diverse personalities that collaborate effectively, and agree that it runs very contrary to the common stereotypes. Modern software development culture is broken in a variety of ways, this being just one amongst them, but I think the first step towards recovery will no doubt involve people learning to be less hostile towards their teammates.
Mostly we love our teammates ( cat people ). We hate stupid processes without any proof of any company that it worked ever ( non scientific method ). We hate Dell PCs that reminds us daily that the future is not about freedom and open standards. We hate management that never programmed anything in their life and like to tell us anything about programming or try to block us from real customer feedback by doing men in the middle attacks to safe their useless existence. I aswell hate programmers that restrict access to invented fileformats to not become obsolete or get feedback. Plus many other things that just hurt the company, final products, user experience, efficiency and the motivation to invest energy to be creative.
That's not true. I have many years in this industry never have met one of those myself
@@rmworkemail6507 How big were those companies and teams? I've only worked in small companies and teams, and only once in a large multinational with a 13-man team that seemed to be doing the work of one to three people where i wasn't allowed to do anything short of rolling back the task i asked for due to the tests failing due to those not having been updated in the weeks before the end of the sprint.
Agree, though a ton of things we do use and that work have no scientific proofs, like most "best" practices
@@doktoracula7017 If it works, that's proof.
My experience from MOBAs is that working together with your team is almost always better than doing what you think is right independently. If you’re more technically skilled, you should focus on supporting your teammates and making sure they don’t get caught. However, there are some teammates that aren’t worth trying to save if they repeatedly throw themselves off the cliff. If you try to help them too much the team will lose both of you.
In my list of horrible professionals to work with: 1. Awful sociopath entitled producers. (The people who feel like a superior race who are bothered when they have to deal with peasants) 2. Rockstar uncommunicative egotistical programmers (including self-made lone wolfs, academic doctorates who never left their bubble, stupid assholes who landed earlier in their career in an important software development studios and keep the smoke to blind the others) 3. Programmer impostors who deny any of improvement. (Individuals that react always in a defensive mode blaming the other for his mistakes. They produce spaghetti code and force the other team members to do the same awful job by shitting about you to the awful producers if you don't comply) 4. Designers with God-like complex (People incapable of defining a design for the other team members to understand who aren't usually there when you need to ask for clarification and details) 5. Burnout professionals (Non-communicative individuals that barely bother to follow the definition of the tasks deviating constantly from the goal) 6. Fraudulent programmers who inflate estimations while they work mostly in their side project during their workday. (In the most extreme cases they don't do anything for weeks taking advantage of being the only ones to know about a really particular knowledge nobody else knows) I've had to deal with all of them. Even I made a lesson of a game development course to train the young talent to not to be like them.
What amazes me, having worked with all aforementioned types in support, administration, and development (amongst other things) is how at the heart of all of the above, the very behavior is enscapsulated in massive insecurity. The need to “prove ones self” every time we step to the table, is tiring. What’s needed is to reach set goals and complete the project. I’ll end this response by asking, what’s your favorite type to work with? On my end, it’s those that are open and dedicated to the team and it’s purpose without the need to outshine everyone at every opportunity.
Jesus what a laundry list, does anyone live up to your expectations?
@@MemoryDealer Dying laughing. Honestly, you could probably pile a few of those together but, gotta be honest, same thought crossed my mind…. However, a better question would be, “We are all our own brand of crazy, what’s the best method for learning how to communicate with everyone’s crazy”? Taking for granted of course, there are, a small percentage (I think) of us, that can’t be but? Live and Learn.
@@TheJacklwilliams sure the fraudulent developer is insecure. Whatever makes you sleep well at night. I think this actually doesn't fit any of those types besides the impostor. Insecure people are probably teh ones who declare the rockstar programmer a myth at best or a hindrance at worst. It's a cope.
I work with a person who I would consider to be half of that list... And I am pretty sure that same person considers me to be the other half the list.😅
In my company (2 developpers, 1 manager and some engineers and technicians using the software we develop) I know I am considered as a Rockstar. When there is a problem, when they want a new feature, when they need explanations about the software they come to me. When the manager needs technical advice for a new software he comes to me. But I know I'm not that good, for me it is just the previous developer (and the other developer) who are not that great. When I arrive in the company there were no version number on the software, no test were being done, the software were full of bugs (but users knew hack to get around the bugs), everything on git was being done on the master branch,... And I really hate that everyone os thinking of me as the great genius who knows everything (even if I dare say it when I don't know something...)
You need to find a better company.
@@a544jh absolutely not...it is better that he stays there and says he bought in a software revolution,when all he has to do is create feature branches in git! 🤣😂😂
Why do you work there? You sound like a professional boxer throwing down with geriatrics on bingo night.
For those saying they should leave, I think it depends on the specifics. If it’s a smaller company that is supportive but just had a bad dev and management didn’t know better, they can potentially make a big difference. But is the culture there ok? Was part of the problem unreasonable deadlines or not valuing the development team? If there’s other devs, are they open to learning and mentoring or are they totally stuck in their ways? If stuck, is management willing to replace them? If they can implement new procedures and get quality way up and improve the experience of the users, that is great. The danger is if there is friction to actually doing that and get worn down and become a worse developer in the process. That friction is a good reason to leave. Another reason to leave might be not feeling like you’re ever able to learn new things and improve your own skills or work with people better than yourself. Even without that, it doesn’t mean that the current job can’t be a temporary stepping stone, but want to be careful of getting too stuck.
The minute in an interview I hear the phrase “rockstar developer” I don’t want the job anymore.
Rock stars typically do not present themselves, they are created by poor planning and a lack of vision. A project is running late and someone puts in the overtime to make it deliverable. I think the focus here lies too much on the person who ultimately saves the day. He is not the problem nor the structural solution. On a side note: some mildly successful entrepreneur once said: "A small team of A+ players can run circles around a giant team of B and C players." And this is hard to dispute.
I'm fighting against myself. Dealing with people is a pain, yet I trudge through. I have overcome my over-engineering tendencies, yet barely. Everyday I curse "I shall not be a Rockstar Developer". I somehow manage to mentor others and tell my teammates my approach. I was once a Lone Wolf, a crow with no murder; 'twas not good.
Businesses want a 10x developer for 1x the salary
Always! 🤔
Regarding the topic of creating drama. I’ve found that a project delivered on time is not always in a programmer’s best interest. On one major project that I worked on, a six month delay caused many actors to distance themselves from the project, and when it finally succeeded, the heroes who made it happen did not have to share the rewards with all the usual parasites, and their achievement had much more visibility. When it became clear that the project would miss the deadline, a VP hired an external audit, and that made the project more visible to the GM, someone who took IT for granted. The GM canned the IT director for lying about project status and rewarded those who solved the big issues with recognition and cash bonuses. This was nice. It’s sad that on projects of the same magnitude without drama or delays, the next IT director rewarded such contributors with “thank you”s and petty gifts like company water bottles, while he and his peers got nice rewards like trips to Hawaii, which he tried to keep secret.
Wow, that sounds like a call center! Especially the last part.
Thanks for the video. I am the Technical Lead for two teams. In one of the teams there is one developer who constantly talks the talk and you'd think on the face of it he knows a lot. He does know quite a bit, but I have found that he is very negative. Or, if a developer is trying somehing new and exploring new ways to solve a problem, he would ask 'Why are you doing this? What for?' This would then prompt the other developer to justify his actions when it's not needed. Instead of ignoring him, they would go off into a debate, and the developer who was trying new things ends up doubting him/herself. Instead, this 'rockstar' developer should be pitching in, sharing knowledge and encouraging creativity. It doesn't help to be negative and it doesn't help to discourage or find problems with every solution. However, they seem to think of themselves as the better developer in the team, but for me, it's the Junior who wants to learn and the mid-level who aspires to help others and push the team forward even though they aren't a Senior.
I'm curious. What's your strategy to deal with that situation? I've witnessed a similar situation and it was a serious problem for management. My best idea so far: Make the rockstar responsible for organizing knowledge exchange sessions and enablement of other team members and make that a priority over everyday coding tasks for him/her.
@@dovahnok well I'm Line Manager for the mid level Devs (he's senior) and I've told them to take onboard any advice they might find useful but if they are in doubt consult me to ensure they are on the right track. I've also fed back to other line managers to ensure that a more positive attitude is nurtured. We don't want to stifle creativity and new ideas.
Have you ever had the scenario where the only person said developer is complaining about is you? Not sure how your team structure works, but this almost sounds like me in some past jobs except it was other devs who were in private telling me, "Maybe you can change the way things work around here." In said scenarios, the tech leads were both the "rockstars" and the "micromanagers." But then when it came to open team discussion those other developers kept their noses down and would say, "Let's just do what the tickets say for now." I've always been supportive of my fellow devs in basically everything they do. (Developers! Developers! Developers!) When everyone is looked at as an equal player, synergy is pretty easy. But the problem I've always seen is teams that get used to being told what to do step by step and are either afraid to speak up, or get so used to a leads way of doing things, can no longer think for themselves. And thusly, when someone new joins the team, who hasn't been indoctrinated or beaten down, whom has good ideas that they like, do not know how to properly support that. Getting back to my original example, "Maybe you can change the way things work around here." can create tension. It becomes a power struggle that the person in the "higher position" will absolutely win. Where devs, after having to endure or be in the middle of this struggle, will eventually backtrack on this and start saying, "Just do what you're told." It's not that they disagree, it's that they don't want the drama anymore. This is what has driven me to quit before. I've even watched this process, with other people, create a max exodus where suddenly everyone is unhappy and starts quitting. Someone presented hope and was beaten down right in front of them. That is very rough to witness. And quit worthy. I've learned to pace myself to the team and have gotten more tactful in handling people who aren't in the trenches everyday trying to make too many decisions about what goes on in the trenches. Same strategies I had to use in the Army, don't ask for permission, just do the right thing.
Why don't you fire this developer? Do you not realize you are encouraging this behavior by not eradicating it?
My program has a "rockstar" developer. Before I met him, I heard he was basically a 1 man team. Not that he worked solo, but he cranked out tons of work. I was supporting an ops deployment one night and one of the Indian guys I was working with that was scrum master for another team said that his mind was "a gift from god". I left the company and decided to come back and ended up on a team with this rockstar. These are the qualities (imo) that make him a rockstar: Patience.. he's always willing to help out and even if he's helping some smooth brain with like 60 iq points lower than him (me probably lol) he never loses his patience. System knowledge.. he has very broad knowledge of not only how our backend/frontend systems work but also of the requirements our customers Accepting of feedback.. there have been a few times where me or others have given him feedback on something and he accepts it. Either he'll say yeah good idea, let's do that instead or he'll say no I disagree because X. Lends his knowledge to other teams.. he's the "most wanted" of our program. People go to him with problems and issues all the time and he tries his best to carve a slice of time for them. He's good at "improving".. he always provides feedback to our product owner on ways to improve an implementation, not only for the customer but for the program as well. He's always coming up with ways to refactor some chunk (i.e. sometimes 10k lines lol) of code to make it more efficient and easier to read/maintain. I've also worked with devs who think they're a rockstar dev that can get away with being an asshole and impossible to work with and no one likes them and they quickly found themselves without a job. Just my two cents. Be knowledgeable, willing to learn, willing to share, and easy to work with and you'll be a "rockstar" dev.
Thanks Dave, great vid. Mirrors my experience (I am now retired). I once worked on a project where my boss would work way into the night, sometimes going home as we normies were arriving in the morning. On this occasion he sent me an email to say he'd found a bug in my code. When I spoke to him later I thanked him for finding it and telling me. At first he seemed surprised that I would appreciate him finding a bug, but it definitely led to an increase in trust.
I like the Belbin references starting around 13:00. Those personality types mesh well with the team roles laid out by Philip DeMarco in his book, Peopleware. I think that is one of the best software books ever written. It isn't a laundry list of "write a class this way", but a pattern for creating a harmonious team that spends its time solving problems.
Dylan Beattie has made some great contributions to the programming community, but probably one of the best is creating a language called "Rockstar" so that "Rockstar developer" is now an ambiguous description that recruiters have started to avoid.
So , this guy is a hero
We could all help further Dylan Beattie's good work, by facetiously enquiring how many years of development experience in the Rockstar programming language is required and which implementation candidates are expected to have familiarity with, on every single job ad that unironically uses the words "Rockstar developer". Bonus points to anyone who automates that process for the common good.
Well, I think that it is also dificult to form a great team, if the mindset is missing. Trust can not be forced into teams. Cultural change is hard to implement. And you need real leadership, which is often the bottleneck.
"you need real leadership" - How did you come to that conclusion? Leadership is in itself a bottleneck since nobody alone can know everything. Most programmers i know, including myself, dont work better on any command, since we are individuals. Biggest bottleneck i know was the lack of customer feedback directly to programmers. The important information was simply absorbed and dumb filtered by middle men attacks from non programmers. Bottlenecks are non scaling toolchains, non scaling hirarchies, bad documentation, bad information flow. Everything was done to kill creativity and therefore real innovation. Creativity is not created by a "leader". It is created by an individual that was given freedom having access to resources without 3 months of burocrazy and as i already said - undistorted feedback. imho.
@@MrGerdbrecht don't confuse leadership with commanding. To lead is the oposite of micromanage. And everything you said should be corrected by leadership and not enforced.
@@MrGerdbrecht found the rockstar developer!
Really good! I agree 100% or very near(hard to meter). What is presented here also applies to lot of other teams, like sports teams. Rarely really good players itself make good team, they are more like composition where different teams members offset other weaknesses while bringing their strenghts to team work to make whole bigger than their part. And overall, creating good products or applications is not just an engineering feat. It also requires business or organization that has sensible goals, listens to engineers and can make working package that gives that psychological safety to so people can work effectitely to common goal. Like said, broken processes can stop good programmers but they can also stop or slow whole teams. Thus organizational cultuer and leadership matters in the background.
A real senior developer is more a coach to unlock the talent of newbies or give a better guideline over the wrong professionals in the wrong place...
Great talk, thanks for taking the time. At first I thought the episode was about Rock* the development game company. :)
Even "We've got a rock star team!" grates on me. Often it seems the most intractable problem we face is dealing with unrealistic expectations. It's like, you can't get approval for a project without over promising, and the only way to do things that you know must be done but that no one else thinks are important is to more-or-less do them covertly. And there's just only so much you can do that way. I dunno. I think I'm the worst developer in the world.. except for other developers. Thank goodness for them.
This is the truest thing I've read here. It is hard to get approval for a project without over-promising. (I think Dave says you need to multiply your estimate x4 and still call it a "guess"). I think that is the root issue, and management that is always willing to make those promises and sign you up for pressurized pain and suffering because their ego is unwilling to be honest about what software development really is.. a collaborative learning experiment each time rather than a production machine cranking out predesigned widgets. A culture change is needed, with managers learning about their business and how to properly develip honest client relationships and expectations.
I recently took over a project written by a "Rockstar" developer who had just been recruited by another company. I ended up throwing out all of his code, not because it did not work, but the because nobody could understand how the code worked. He was so sure of his "Rockstar" code he did not believe in testing, so no unit tests, no test environments and he released to production directly from his IDE, so no build pipelines. Two years of his work down the drain and at least a year of my team's time to replace it.
Ouch!!
Reading the descriptions, I am somewhere between "Plant", "Specialist" and somewhat "Monitor Evaluator." Most others appear to be clearly not aligning with my general personal intentions and interests. I like to bring up solutions, creative and/or novel ideas, can be quite critical, objective, very decisive, may talk or discuss too much and am really invested in C#, optimization and high code quality. But I am not good at managing people, find "polishing" projects tedious and boring, and have a chaotic work routine which collides with "organized" work routines of others.
Thanks for the reference to the Belbin team roles, it was interesting to do the test. The best team I ever worked with had three key people: One "Resource Investigator / Shaper", one "Completer / Finisher", and me as "Co-ordinator / Monitor / Evaluator". True example of 1 + 1 + 1 = 25.
This was very interesting! Thank you! I really enjoyed looking at the Belbin's examples. Never came across that before and have worked in many teams over the years.
My friend I am living exactly what are you telling me here. I worked in companies where the process killed good ideas and talent. I worked with people that called themselves rockstars but were bad team workers and bad coders. Now I think the key to success is work hard, have a good team, set goals based on what others are doing better than you and more important : Trust in your people
OMG, glad I watched this video. This isn't just limited to programmer teams. I work in game dev but on the art side. This is totally relatable. Great insight on Belbin's research, I should look him up. Thanks!
I'm a big fan of yours and leadership at my company are definitely sick of me sending them links to your videos. But I think you're a bit off base here... I'm Autistic, and therefor what many call "Neurodiverse" and as a result I think very differently than most other folks. Many of my peers consider me a "rockstar" because of numerous examples where I've seemingly worked miricals. After one incident my manager exclaimed "I need a whole team of people like you!" but I stopped her "no you don't" see, the thing is, if you were try to figure out which languages I'm fluent in, it's literally none. Seriously. But what I can do is walk into just about any languages blind, and figure out what's going on. To me, the principles are all generally the same. So, I'll never be your heads down coder with a high story output. But when that new tool we paid millions for tanks in the middle of our deploy, and the entire team spends hours trying to fix it but no-one had any experience in it, I'm the guy you call. When you're highest output devs are mired in some intractable but critical problem, and therefore unable to have the high output you need, you have then schedule a Collab with me... I won't know all the intricacies of the specific language or topic they're working on, but I think so wildly different than most of those around me, I often lead them to the solutions relatively quickly... Often much to their own surprise. So I think it's better to say that the most critical aspect to any development team is have a DIVERSE team, representing as many different ways of thinking as possible. It's it important to have someone like me on a team? Yes (or at least I hope so) but it's also important to have someone with a very high output, and predictible, story output. In fact, one of my favorite coworkers isn't particularly fast, or clever, but she is quite literally one of the nicest people I've ever spoken to. When you're talking to her is like wearing a warm sweater while eating fresh made brownies. When another team starts getting angry in a meeting, or an executive is upset about something, or even when we're bickering amongst ourselves... I get hold of her and have her join the meeting. It immediately brings the temperature down and by the end we're all usually smiling and feeling much better about things. The thing is, heads down high output codes are important, but they're a dime a dozen out of our local community college. A developer with enough experience to understand what we're all talking about and also the personality to help put a smile on everyone's face? That's a rare thing. So I think it's important to have both types on your team. Or maybe to say, everyone's a rockstar at something, and it's better to figure out what that is for each individual and then exploit it as best you can.
I think that what you describe is what I was trying to say with this video. Your skills are complimented by others that you work with, theirs are complimented by yours. That is how great teams work, and that is backed by research into the psychology of teams, as well as your practical experience. So I am not sure where you think I am off target, because I think that we are agreeing 😎
@@ContinuousDelivery now we just have to find a way to explain this to leadership in a way they can understand as well. :-D
Thankyou for this great presentation. It was very informative.
There's a tendency at my work for "Programming by Remote Control." But I honestly think it comes from fun of solving tech problems. However, implementing the solution requires a skillset many people don't want to put in the effort to acquire.
It's like a math class in school with a genius and teacher enamoured in him adjusting difficulty level to the genius inevitably dragging all the class (also demotivating everyone with endless comparisons) which can't keep up, do not get served with proper understanding and starts getting behind without own fault. The genius will always find his spot here or there but the collateral damage to majority, resentment, confusion, burnout accumulation could cripple next generation. And the side effect of it can be hostility towards the next prodigies despite their humility. The worst is the invisible knife. Snake of chaos. Like the collective karma, hidden categorisation, the army wave bullying. Chain reactions like pathology subconsciously becoming a custom/culture breeding pathology cyclically. When you can't find the reason for things happening you are forced to live in a buggy process.. getting suspicious also of the unsuspicious.
I've seen rockstar code with 7+ indentations with single character variable names where _e_ stands for _Handler_. The trainee then copied and pasted this all over the project. The rockstar saw this as a confirmation that he writes excellent code, but the Trainee had no idea about what he was doing. Later no one figured out what it actually does and why. This really did harm to the company in their capacity and progress of the projects.
When I read the title I geniualy thought it was referring to the developers from rockstar games lol, great vid I've witnessed what you described first hand, I wasn't aware there was term for it.
Hurry up GTA 6 :P
To be honest, i would prefer 5 rockstars arguing all day over what i find in many crisis projects i review: teams full of developers with
I have worked for 3 startups now. I agree having all talented people in the same team is gonna be disaster.
I think the work load creates Rock Star myth. Some devs work evenings to finish the tasks and companies encourage them. They behave hostile to other team members who work just 40 hours weekly.
is it impossible for you to imagine that some people simply are more skilled? is everyone just a Junior dev until he works 2 hours a day more?
Very good, and yes cooperate teams are the way to go. But I've also been grateful to one or two "stars" on certain projects that solved key problems that I couldn't or didn't have time for. As an aside, I've also appreciated the humorist, every project should have one, lifts the mood.
A team that ends up with a Rockstar developer it's a symptom of things are going wrong. Dysfunctional leadership, dysfunctional teams
As I reflect on my time in my current team, which ends soon. The team is important. And certain environments require certain kinds of people who work well together in that environment. Developers who deliver in the expected way. That can communicate with the project people who need constant status. I did not make that cut. I pointed out our problems with not managing the uncertainties. But it was a very strict project. Conditions that I, and an outlier, could not work in.
The rock band analogy should also include the aspects of the band's "management" and how the administration is allowed to happen (i.e. it may not even be visible; think 'office space'..). Often the best performing teams will also have 'systems' (people and/or facilities) in place that allow them to get on with their creative and productive tasks without being dragged through the mire of niff-naff and trivia. It's like the guy who was sweeping floors that was helping get a man on the moon! (JFK, at NASA Space Centre 1962). Every one facing the same direction.
I do feel I'm very good, in my way. And I try to be very clear about what my strengths and weaknesses are when I'm in an interview situation. I work best with a team where my strengths and weaknesses synergize with other people on the team. I'm really amused that 5 minutes later, you basically say the exact same thing. :-) And I avoid jobs where the job description is "rockstar developer". That's not who I am. And I agree with you about developers who think of themselves as rock stars.
I usually call them “cowboy” programmer. Fits better I think
agreed. especially with what he describes as them leaving a mess
I just completed a project to automate a manual reporting process. Some people think I'm a rock star, others don't. I know that there's code I can't write, at least, not in a reasonable time frame and I have to work long hours in the wee hours of the morning to get certain tasks done. Right now I'm on loan to another department, to prove my worth. The tools I use I think are good, but I don't know anyone else who uses it, also, I've never worked with anyone else, as part of a team, as a developer in my 30 years of coding, and I've never worked in programming job before, until now. What I have done is let my experience on the job guide me to make things better. and I've had a few private jobs here and there. but never full time as a dev or part of a team
7:45 Belbin did research into teams too... he found if you make a team only made of Rockstars..... ... ... You end up with a band!
Love this one! Team members cover other team members' weaknesses... never thought it like that. What a gem!
Exactly! That is my take-away from the video. In future interviews I am even going to try to say them "I do not try to improve my weaknesses, it would be a waste of time and effort, I rather prefer to enhance my strengths and find a team that other members will cover for my weaknesses , in the same way that I will cover for their weaknesses...". and have a good look at their surprised face (most probably trying to hold my laughter) !
I am assuming that better room upgrades the Jack Daniel's to a nice single malt scotch? Great video. Thanks.
That would certainly be my choice, but it is a bit less "Rock 'n Roll" 😎
For a year my biggest ambition has been to be an "average" developer. I think it's healthy for me and for everyone around :)
Yeah I think there’s a reason programming is often called a craft. There can be aspects of art and science but being pragmatic is also very important.
Out of curiosity, when did you come across Belbin's ideas on team work? Maslow's ideas on people's hierarchy of needs and Belbin's ideas on high functioning teams I found to be equally fascinating when I first came across them.
Not sure I remember when I first came across them, but it was a long time ago 20 or 30 years ago. I think my wife told me about it when we were discussing how teams worked, I was probably grumbling about my team at the time.
I've found that a developer is someone who is not only developing ideas, solutions and code, but also him/herself as well. Being able to adapt to situations, tooling, way of working, collaboration etc takes a lot of learnimg and experience and often a lot of soul searching and reflecting. A rockstar dev seems to be someone who excels at some areas but completely fails in others and not being able or expected to adapt at all. It's usually a bit of give and take that's needed. If you can't adapt, teach and/or learn, soon you'll be working in an outdated and irrelevant way.
Yeah, I tend to comment before even watching the video. The only rock star developer should be the company. If you don't have proper corporate management, ethics training, documentation, knowledge transfer security training, SLDC, then you have rock stars. Or just whoever can pull the wool over mom and pops eyes. Although talented developers at any level who can sling bullet proof solutions where others cannot (the ones work harder, foresee scalability, portability, modularity and don't cut corners) are most admired for their genuine humility
Very insightful thanks.
I'd be interested in how these Belbin roles correlate with the OCEAN scale. A teamworker sounds like a developer with high-trait agreeableness.
I think this misses a deeper aspect of what managers want in a "rockstar developer". There are a lot of risky projects out there that may be beneficial if they succeed, but managers will want to minimize their losses if it fails. In this case they're looking for a entry to mid-level developer who has a lot of confidence and knows pretty well what they're doing, but don't know the broader reasons that they're being set up to possibly fail. Basically "fools rush in where angels fear to tread". A lot of senior developers will see the warning signs and avoid projects like that, or be put on less risky project that are more foundational to the bottom line. If the "rockstar developer" succeeds then the code may need to be re-done by a senior developer, but element of risk is gone.
I find that once you get beyond the really poor programmers I have a hard time rating one programming as better than another. Mostly because the knowledge ends up so specialized that it takes a group of people to do anything. I work on scientific and engineering software which involves a lot of complicated math and the skills needed to solve it, optimize it, improve the math, etc. are just pretty specialized and nobody can do it all by themselves. Who is the better programming between the person that wrote the solver and the person that numerically stabilized the math?
That’s a good point about different domains too. A lot of people think of dev in terms of enterprise software where managing complexity is difficult and knowledge of the business is helpful but actual specialized math is almost never required.
Very very well put, thank you.
Same story as "Ninjas" and "Hackers" in the team.
I think the biggest hurtle I face on a day to day basis is time. Our team never has time to do things right and whenever we end up with extra time we never get to take care of our tech debt. We instead take care of some other aspect of the companies tech debt like documentation... then we get scolded when they ask us to do something and we explain to them why it won't be so simple.
The problem is that its a vicious circle, the more you defer doing higher-quality work, the bigger the hole you are digging, and the bigger the cost, "Knuckles" will come to call eventually 😳 "Types Of Technical Debt And How To Manage Them" kzhead.info/sun/ZLF7oK-Xh6p7oY0/bejne.html
This video got better as it went on. Glad I listened to all of it.
There is a programming language called Rockstar. So you can be a Rockstar developer without being good at programming. Here are 3 versions of Hello World in Rockstar: say "Hello World." whisper "Hello World." shout "Hello World." The point is the programs written in Rockstar are quines with 80's metal power ballads.
Nitpicking here, but it's easy for most to be above average: `[1, 10, 10, 10, 10]`
The problem with being a rockstar developer is that people start expecting more and more until your entire life is consumed by work.
The problem with being a rockstar developer is that you're working on legacy code for a 10 year old game
Bell curve, the limit of the distribution of the nth row of Pascal's triangle, as n approaches infinity
There usually is misunderstanding what is Rockstar. Rockstar is a person, which knows ( intentionally or accidentally ) what the auditory ( users, key stakeholders ) wants, what the conditions are ( historical, social, etc.), what kind of resources are needed for achieving a certain goals. Is it that simple? When you realize how this is complex, you will understand what the Rockstar is. Yes - sometimes Rockstar can leave a mess code by cutting some corners, so deadlines to be met. But... let we do our calculations before criticize ... What will happen to a project if they do not do that ... My experience says next... stakeholders start to be nervous... this leads to situation in which stakeholders start to not to believe that the project will be successful, this leads to situations with lowering the trust to the project team... lowering the resources, and finally the project is closed with great fail... Who needs this ? While the Rockstar approach, at least gives the project more lifetime. Yes - the code probably will need improvements. And it will need improvement in any case... And Rockstar gives a chance this to happen... Rockstar is person that can take a difficult decisions for good of the project... Don't mess a Rockstar with a narcissist developers, which try to convince everyone that the world can not exists without them. This is very frequent mistake, and this mistake costs a lot to companies which can not make the difference. To understand real Rockstars - look at The RollingStones rock band - Mick Jagger and Keith Richards are both Rockstars, but they leave their narcissism when they composing. They are leaders, but smart leaders - which knows when to stop back in the name of the greater good.
Love that ending quote by the netflix CTO!
Everyone can do simple CRUD. Rockstar is one, having insane amount of knowledge, that can work beyond that. It's one engineer in a team of coders. One, that mentors a team, while knowing the solution, so they can solve it together.
Not everyone would give up their life to become a "robot".
I would like to point out that while we should work to each persons strength, not working on your weaknesses, taken to an extreme is sure to get everyone to hate you.
My manager is a narcissist and that makes it difficult to suggest something contrary to his ideas even if I know he is not correct. Psychological safety has buried inside this politics of blaming. The first thing my team leadership decides in any undertaking is clarity about who will be blamed for this, they cover it under the word responsibility.
I think that Dave is criticizing a style of IT Management/Leadership that focuses on few developers for their deliverables instead of focussing on Processes , Team Delivery's Capabilities and each team member accountability/productivity. I agree with him. Who are the Rockstar Developers? Lot of people think that Rockstar Developers are yahoos, cowboys and developers who have least respect for processes, procedures and methodologies . My definition of Rockstar Developers is that they are passionate developers who love their jobs and spend their own time to make sure they are up-to-date with latest changes in software Engineering. Can Process and Rockstar Developer coexist ? Yes. We should use Rockstar Developers to solidify the processes. e.g., If we are going to use CI/CD, TDD and DI , Rockstar Developers can be used to set up the initial framework and train the fellow programmers. Happy Programming.
Except they don't train. You are trying to find a way around this, but to no consequence as a bad practice is a bad practice anyway
I don't disagree with anything you said. Anytime I get grief about the performance of my teams. I tell them to get HR and the hiring process out of my way. I give the applicants a IQ test and I don't hire anyone that has a IQ less than 135. It certainly pisses off folks that they aren't smart/creative enough but the common denominator over the last 43 years of programming is this 20% does 80% of the work. That 20% are always people with high intelligence. Performance evaluations are simple... none of that touchy feely shit. Number of lines written / total bugs sort ascending. The top of my list gets a good raise, 20% get a decent raise the rest get the minimum. the pareto curve maybe a bitch but it is reality. Hiring based off degrees and certs tends to create disasters as folks think the know more than they do... and they are very happy to tell you how much they know. I wont even get into the diversity and equity business where the competent are replaced by belligerent chair warmers. But when performance fails I ask which of "those" guys can I fire. I guess that at some point this get out of jail free card will disappear and I will have to go back to a real working shop. The only programming practice I require is testing and the rule is as follows if you call a method write a test. That's it. Well and December 1st we start fixing outstanding non-critical bugs ie busy work. Being the smartest guy in the room. I am smart enough to know I don't know everything. So I get out of the way and let my guys do what they do best. But I will argue that most programming managers are garbage. And those of us in upper management are bureaucrats out of touch with what is ACTUALLY happening in house.
The mistake is to put rock stars in a team. They work alone. Almost any famous piece of software has a rock star behind it, sometimes two - probably not more than that. You all use Git, right? Any of you use Linux? What do you think of the Task Manager in Windows? One guy did that, and no one asked him to, they just didn't stop him.
3:23 is brilliant
You have taken my career to the level. I want you to know that Mr. Farley.
Rockstar developer as self-employed indie or as a little gear in MAANG?
maybe the difference is "rockstar" vs "unicorn". Rockstar wants the fame and might be somewhat talented but the mentality is different than a "unicorn" who shares their talents/skills to help grow the team's capabilities.
Tbh companies that expect rockstars irk me. I need that team by my side and a process that isn't broken. There's a lot to fix in process in my current place but I do get autonomy at least! But a small team is always best
Rockstar developer: Creates complex solutions to solve simple problems (where very often much simpler off the shelve solutions exist).
That isn't what the rockstar dev is
@@dandogamer in my experience it is. Most people that claim to be rockstar developers are shockingly bad and like to spend a lot of time on reinventing frameworks. I'm not talking about experienced, talented people who know what they're doing and are usually quite humble about the great work they're doing.
I know many programmers who likes to be seen as Rock Stars: they fix issues quickly and they show up in the last minute to save the company. But it happens only because they how where to change their bad legacy code without breaking things.
Thanks for the video =)
A "rock star" is a manufactured personality whose sole purpose is to look good but must be supported by a small army of people behind the scenes.
You're totally right. I've understood it at some point being one. And I decided to quit being a software developer. I... chose something else.
Well, technically, it's entirely possible for most developers to be above average if the distribution of the measure of quality is skewed left. What you mean is above *median*.
I don't apply to jobs asking for "rockstars" The amount of churn and dysfunction should not be discounted.
nicely done!
I would say the substences are different. Majority of DEVS I know do loads
I agree. I hired Mick Jagger to write some industrial control code, and he was rubbish.
Enlightenment video. I'm left with the following idea: Maybe it would be better trying to be part of a world class team instead of trying to be a Rockstar Developer
Then you got my message - thanks! I think that would be a great outcome, when I have landed on teams like that, I have had the best times of my career.
I got so confused before I realized this wasn't about the *language* Rockstar.
My idea of a good developer is the opposite of a rockstar. I have seen a few of them, one in particular who one day got fired on the spot for loudly disagreeing with the CEO. The only person I ever saw that happen to. He had a greatly inflated perception of his own skills. Rockstar == ego tripper who can't take one for the team.
5:00 cut corners to make the release? that sounds like a positive. but you follow it up with 'they left a mess of the code'? as a rockstar developer i feel like 90% of developers make really dumb basic choices (like using an OOP pattern) and cutting that corner makes everything more manipulable. So when you say you spent weeks to fix it, I can't help but feel that's what the 90% of devs do, out of desire for consistency in something that ultimately has to act like spaghetti. edit: ok, so just to confirm. you are talking about adding 'classes'. while some languages require this, you really need an experienced C programmer to get you back on the right path
What about 343i ?
I agree that the constant guitar solos during coding can get a bit annoying.