Then you will need two senior devs. This is because rockstar devs rarely want to mentor junior devs nor attend meetings.
Most inventors are not professors.
Then they aren't a rockstar. And frankly, I've spent my career cleaning up the obfuscated, badly documented, untested code of "rockstar" devs.
The idea of a "rockstar" you seem to be referring to has, in my experience, been a dev who can go into a corner and pump out high volumes of code with little supervision or collaboration. That's great, except no one else can make sense of the code they pump out, so when it comes time for the next guy to add a feature to the rockstar's mess it takes 2 to 3 times as long as it should.
I've also had to clean up messes by rockstars who made unilateral decisions about incorporating new technologies into a product. Like building out a single part of the product in React with out asking anyone else. You see, the rockstar didn't like meetings and didn't want to make the case to the rest of the team for why we should all learn React and gradually switch over. Instead, he just stuck it into the code. So now, you have a couple of views built as React components, and the rest of the thing is in Backbone. No one else knows React or has time to learn it, cause we're blazing ahead really fast. They just get very confused when they have to change something in those components and it takes them forever. But the rockstar got to have his fun and play with new tech.
This conception of a "rockstar" isn't a great developer... it's a selfish, cocky developer. When you hear "rockstar" dev, you shouldn't hear great performer. You should think of Keith Moon trashing his hotel room and driving his car into the hotel pool.
A great dev knows the value of documenting their code and writing testable code. A great dev knows the value of taking the extra time to make code easily understood and easily modified -- that sweet spot between spaghetti and over engineering. A great dev loves to mentor junior devs, enjoys walking other devs through their code, is happy to discuss design decisions with the team, and willing to admit when maybe their idea isn't the best one.
A great dev doesn't think they are god's gift to code, they are humble enough to understand they are one part of a team. They put the team first and work hard to teach others what they know, while always remembering they don't know everything.
That's why I've always told people that I'm a "studio musician" developer. Not a rock star, but a competent professional the studio calls when they need to make a record.
That's what I'd been saying for a while -- the best devs are session musicians. They have enough all-around comoetence to deliver what is asked for for that particular recording.
Normaly session musicians are better than rock stars James Jameson (funk brothers) was a better bassist than Paul McCartney, and Paul would admit that.
I have worked with a Musician with Phd in music who taught him self coding after an accident broke all the bones in his feet (drink had been taken)
It was fun in the pub when some hit tracks came on he would say ah I think that's one of mine :-)
Near as I can tell, the term stems from the 80s computer gaming industry, in which the game studio heads got the idea to promote the individual developers by name as if they were rock stars, and oftentimes attempt to treat them to the "rock star lifestyle" (girls, parties, etc.) in order to keep their output from flagging. In those days, games were often written by teams as small as one, and no bigger than a handful -- and the studios themselves were often fly-by-night outfits whose idea of "product packaging" was a Ziploc bag to ship the disk and manual in.
Eventually in the 90s, some developers really took the rock star bit to heart and started plastering their own names all over their output (cf. "John Romero's Daikatana", "American McGee's Whatever-American-McGee-Is-Working-On-Now"), but for the most part, developers at the time hated the rock star characterization.
Electronic Arts started as an outfit for people like this, as did Activision. It's saddening to see how much their ethos has changed in the ensuing 30-40 years.
A great dev gets out amongst his user community and finds out the real feelings of those who are using the software. The great dev tries to understand the actual user requirements (not just what has been supplied by the design docs). The great dev listens to the criticisms of the users and discusses what can and can't be done.
I don't disagree with your "great dev" qualities but there is more needed to make a "great dev". Otherwise all the documentation, code ease, mentoring, being a part of the team, etc. is not going to make the code useful to anyone.
The whole "rockstar dev" branding has always made me cringe, but my opinion is software should be made by rock bands. Sometimes you have to play bass and not get laid.
First off I hate the phrase "Rockstar dev" because it gives the impression that someone can be successful without the support of the team, which is wrong.
Second, I hear this extremely often: Rockstar devs don't like to mentor, Rockstar devs don't like to write documentation, Rockstar devs don't like to write tests.
At what point do you need to reevaluate your definition of a rockstar dev?
The hiring filter is a powerful thing. It allows you to find very special people if you know how to look. It's also a feedback loop. Getting momentum with a program like this is the hardest part. Once it's going it practically self sustains. The biggest part of your role becomes quickly firing any mistakes.
Rockstars are lone wolves, write unmaintainable code that works quickly for demos but gives the company pain for years to come as nobody can figure out how to make it stable or maintain it. A rockstar's reputation is self reinforcing because it's easy to get a lot of shit done when one doesn't have to worry about maintainability, communication with the rest of the team members or the company at large, and service.
Senior devs balance development work and "service", a term I'll borrow from academia - hiring, mentoring, speaking, writing docs, etc. They either find fun in these tasks as well (I legit enjoy interviewing and mentoring), or understand this is a necessary part of being a well functioning team player at a senior level.
You hire the rockstar to write version 1. That's the one that gets you to market fast, and the one you should be planning on throwing away. It's the one you keep in production as your non-rockstar ninja and guru coders write version 2 from scratch. Once you release version 2, you really need to fire your rockstar. They will never be happy in maintenance mode, and that's fine, because they're usually bad at writing for maintainability.
Then you can hire some boring reliable folks from the khaki-and-polo brigade to help upgrade version 2 to version 3. This is when you have an opportunity to hire juniors and mentor them on what good software actually looks like, and how to make good-enough software better. The ninjas will probably leave at this point, and if they have done their job, the company will never need that level of expertise again in a permanent employee. The gurus will stay on to be an expert in your specific system, and teach the new people how to preserve its grandest traditions.
The problem is that a lot of companies never get to what I call "version 3". They might slap higher release numbers on it every so often, but if they never did a clean re-implementation of the quick-and-dirty prototype, that's still "version 1.X", no matter how high the numbers go. You put a junior in that environment, and they're not going to become a stable maintenance developer, and that's where the majority of the jobs will be for the foreseeable future, especially for inexperienced people.
To sum up: rockstars live fast and die young; ninjas quietly demonstrate incredible skills, and vanish; and gurus are the high priests for your established project, who will eventually pay off all your tech debt, if you let them.
There are different breeds of senior developer, and you really want the gurus teaching juniors when they start to run short of other useful things to do. If you don't have the kind of company that is mature enough to evolve a developer into a guru, you won't be able to handle juniors. And there aren't enough companies that can handle juniors. It may be because they aren't honoring the full software lifecycle that includes the long, long tail of maintenance mode.
I think the never getting there often happens because management isn't aware of the current quality of their software vs hypothetical quality of a rewrite.
And I get it: I imagine every one of them has been burned by an overly optimistic developer. "It'll be rewritten in 3 months and run 2x as fast" types.
As a discipline, inculcating "respect that the years of person-work in the current version weren't done by idiots solving unimportant niche use cases" would be very healthy.
Labels like rockstar, guru and ninja are labels we don't need. We need competent generalists and competent specialists who can work in teams as well as work alone and can communicate with those who are part of the team or part of the management and user bases.
When a person takes on for themselves labels like rockstar, guru, ninja, etc. I don't doubt that they can write code, but I certainly doubt that they can write code that fulfils the needs of those who will be using it.
Labels likes these are a detriment to the profession. If we want businesses to take note and consider those in the IT profession to be anything more than ignored, we need to lift our game a long way.
What is IT known for (in the general sense), games, social media, search engines and lots of crappy software that users have to fight to get anything done.
Yet we have people and companies that produce great software that fulfils the needs of those who use it in a way that is not detrimental to those users.
It's coming up to forty years that I have been involved with the industry and I hear complaints every day from users who are frustrated by the inconsistencies in the software they are using, whether it be social media, business software, games, etc.
In general, as an industry, we are far too arrogant about our own self-importance and what we develop. Whether it be the likes of Apple, Oracle, IBM, Google, etc, the industry has forgotten that they only exist as long as people will tolerate the bull dust that is thrown at them by these companies. We are always looking for the "next big thing", yet many of the actual needs that we could be filling are not being done. We like flashy and not substance.
We don't need titles like that at all. Let's change rockstar to MVP Developer, Ninja to Builder, Guru to Experienced Builder, and the 3rd type of developer described in GP to Maintenance Developer. I think the industry could go a long way if it admits that it needs all 4 of these types of developers, so that expectations were transparent for employees and needs are transparent for developers.
I object to those terms. The rockstar is most definitely not the MVP. To the extent that I have worked with any, they are the insufferable primo donnos that fill the garbage bin and set it on fire then they proselytize their own trash fire to management until they think it is "hot", "energetic" and "enlightened". The rest of us then get stuck dealing with their legacy issues. If you're going to title-ify it, how about "prototype developer"?
The others can be "foundation developer", "transition developer", and "maintenance developer". It's still meaningless as long as different companies won't standardize on those titles.
We likely all know which category we belong to now, and which one we want to be. We also know that any company that asks directly for a "rockstar", "ninja", or "guru" is probably one to be avoided.
Yes to both of these, but there are other options as well.
The frustrating ones are those who talk a good talk about "doing things right" (and, generally, talk a lot...), but then work on something for an age and come back with a solution that's objectively worse than the "RIGHT NOW" solution we've been using in the interim.
I have that dream too. It seems that the more years I spend as a developer, the less I am comfortable to taking on technical debt. Maybe it is because there are so rarely opportunities to pay it off - and the interest rate is almost always way higher than anticipated.
This is not a great example.
In academia, that's because they are fundamentally different jobs in most cases.
Most of the professor roles are not teaching their research, and where they are, i would bet your best professors are the inventors. But most are researching x and teaching y.
By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
The notion that people who refuse to mentor or attend meetings (assuming these are symptoms of the same "not team player" phenomenon, and not something else) are rockstars is, imho, pretty misguided.
Even if you assume the 10x people silliness is true, each person mentoring 2-3 new people and building them will make the organization more productive than your 10x person fairly quickly.
(Again, situation may be reasonably different if you only will have a team of one or two, etc)
> By contrast, in software development, the devs should be teaching, because what they are teaching is what they are doing on a daily basis, and the knowledge they've learned in how to do that well.
I don't agree, senior tasks are often much more high-level and related to figuring out requirements/stories, or their tasks are hard enough that explaining them to juniors is not the most productive.
I'm kind of confused here, so i feel like i missing something.
The way this is written makes feel feel like you you don't think the junior devs need to become competent at those high level tasks over time?
Otherwise, how do they become senior devs if not by things like "gradually delegate higher level work, see what happens, help them learn by mentoring them based on results".
It's not like they read a book and suddenly know how to do that.
"hard enough that explaining them to juniors is not the most productive"
I strongly doubt this. Most of the differences i've seen over the years are in approach to complexity, and not level of complexity themselves.
If you don't want to teach, you're not a rockstar. The best developers I know have always been ready to show and explain what and why and how. Inventors love to talk about their inventions.
Teaching isn't a simple matter you can flatten down to like/dislike.
One aspect of teaching is explaining your inventions to your peers.
But another aspect is telling a new graduate what a version control system is and why you need one. Then doing the same for your build system, continuous integration system, staging environment, code review, bug tracker, style guide, and so on.
Seems to me those are quite different skills - I can easily imagine a person who is good at / enjoys one might not be good at / enjoy the other.
To a first approximation there is no such thing as a "rockstar" developer. I mean a few of them exist, but the actual stars (not poseur wannabes) are already locked down doing other things so it isn't possible to hire them anyway. If you're hiring or building a team you have to target developers who are actually available, not the stars.
It's astonishing to me that I discovered the other day that Fahrenheit is only used by United States, its territories and associated states (all served by the U.S. National Weather Service), and 3 other small Caribbean countries. All other countries in the world are using Celsius scale from metric systems.[1]
Because water is arguably the most important substance to mankind.
In the celsius system (and at standard pressure and bhawawa please point out technicalities) - water freezes at 0°C and boils at 100°C. That's pretty simple to remember and makes actual sense.
In fahrenheit, body temperature was supposed to be 100°F but its not because when the guy measured his temperature, he had a fever. Congrats dude. First strike.
It freezes at around 30°F but not quite. The scale just doesn't make sense for any intuitive application.
If you think that body temperature should determine the scale of temperature measurements, think about how often you need to know your body temperature vs. how often you need to know how hot it is outside. "is it tornado season? nah, its only about 0.7 body temperatures outside". Besides, to anchor a scale, you need 2 reference points. Not just one. Fahrenheit is just a turd.
On top of that, Celsius scales just like Kelvin. 0 Kelvin is the point of absolute zero. The point of "No temperature" - to keep things simple.
0°C is 273.15K and 100°C is 373.15K - which means that Celsius is essentially Kelvin (the unit that makes scientific sense) adjusted to a level that makes sense for common man applications.
That explains why everyone is using Celsius. Nobody can tell you why the US does not. Its clearly because they are some very special snowflake. Same reason they use retarded units like inches, feet, yards, miles, ounces and pounds.
The business about the fever is a myth. Fahrenheit's original fixed points were a mixture of ice, water and ammonium chloride, at 0, and normal human body temperature --- at 96. He then redefined it in terms of the freezing point of water and human body temperature, at 32 and 96, so as to have 64 degrees between them.
After his death in 1776, it was redefined based on the freezing and boiling points of water at STP, at 32 and 212 (a difference of 180). So in fact it uses the same fixed points as Celsius, and has for hundreds of years.
Also, you have Celsius and Kelvin backwards: Kelvin was originally formulated to use the same sized degrees as Celsius, not the other way round. Celsius was first. (Although Celsius is now defined in terms of Kelvin.) See also Rankine, which is the Kelvin equivalent to Fahrenheit: absolute zero is 0, the freezing point of water at STP is about 492, and boiling point is about 671.
Did you know that the original Celsius scale ran from 0 at boiling point to 100 at freezing point, i.e. backwards? It was reversed after his death. Fahrenheit didn't make that mistake!
The body temperature the Fahrenheit scale was made to work at was axillary (armpit) temperature, at 96°. That's a multiple of 32°, and both are evenly divisible by 16, 8, 4, and 2, making marking of the scale easy. Both are common temperatures that a person would be likely to experience (whereas 100°C is something you'd hope not to experience, but rather to observe). That leaves zero as "frikkin' cold" by most European standards. It's a perfectly reasonable scale if you're not obsessed with base-10 values.
It's hard to not be obsessed with base-10 values, when your numeral system is base-10.
I am sympathetic to the argument that 12 (but not 16) would make a better base. But that argument only works if it's uniformly applied bottom up - base-12 everywhere, and then we define base-12 metric prefixes, use 144 degrees between defining points for temperature etc.
As it is, the incoherent mix of base-16 and base-12 that is common for American customary measures, and base-10 used to actually write them down, is a mess.
if you think that they're "easily divisible by 2", why not tell me what 832 is in terms of exponents of 2.
Thought so. Most people have enough difficulty understanding multiples of 10. No need to make it more difficult for the mentally challenged. For us scientists, factors of 10 prove really helpful.
> Common usage shows that Americans have no issues adopting the metric system, just very selectively. Americans currently enjoy:...
> Monthly power bills that are specified in Killowatt hours
Kilowatt-hours are not SI, the metrics unit is the Joule (or MJ in the case of your power bill). However the US joined the Metric convention in 1878 and has used the internationally standardized metric inch of precisely 2.54 mm since 1959 (except, I believe, for surveying)
Plenty of so-called "metric" countries continue to use customary units such as miles (UK) though those are based on the metric inch. I still hear people talk about their weight in stone. Germany uses a metricised pound (Pfund) of 500 g. Japan still commonly uses the tsubo (坪) for land. India also uses a variety of official land measurements, and also doesn't break its numbers symmetrically into blocks of 10^3 (preferring lakhs and crores). etc etc
I am not a fan of the metric system in daily use (though I use Celsius). For work I have used the official systems MKS and (US) Imperial, but have also used cgs and imperial imperial. For building a staircase, making the riser a convenient 2/3 of a foot is physiologically ideal.
If there is a god it was cruel for giving us five digits on each hand. Far better would have been one fewer or, even better, a thumb on the other side.
A "metric pound" of 500g is an argument in favour of metrication. Pfund is just a special name for 500g. It's not very common anyway, probably following a reduction in people buying food by weight from markets.
2/3 foot is 203mm. You wouldn't notice any difference with stairs of 200mm.
The US has adopted the metric system just as completely as, say, the UK has. (Watch UK television and look for how many times the script will say "miles" or "pints" or "pounds" for weight or even better, "stone"!)
The UK in daily use has as many imperial measurements left as the US does. Americans are just more honest with ourselves about it.
> The US has adopted the metric system just as completely as, say, the UK has.
I've lived in both, that's inaccurate.
The UK is mostly metric with exceptions (MpH, pints, pounds & stone for "people weight") but in all other ways it is metric, cooking is in metric (grams, liters/milliliters), parts are in metric, temperature is in metric (centigrade), and most measurements are metric (metres, cm, mm, etc). It is a metric country with a few leftovers.
The US conversely is imperial with exceptions. Meaning most "day to day" activities are in imperial units with certain industries (like science) and activities (?) being metric. But if you go buy a cookbook in a US bookstore then good luck finding a metric one unless it is an international cookbook (it will be in "spoons" "cups" "ounces" and so on). You buy a new cookbook in the UK and it is almost certainly metric unless it is from a used book store.
So, no, the UK has adopted metric much more thoroughly than the US. To use made up percentages, the UK is 65% metric, the US is 20% metric. Again, I've lived in both for a decent chunk of my life.
Whereabouts in the UK do you live? This isn't at all my experience...
Old people might still commonly use Imperial gallons, Imperial pints, pounds, Fahrenheit, inches, and so on, but the cutoff age for this is rising. I'm 39 and I don't routinely use these.
I use some context-specific Imperial units: feet (people), stone (people), Imperial pints (beer), miles per Imperial gallon (car fuel economy).
Miles are pervasive, and will probably never disappear. (Miles per Imperial gallon is obviously stupid - but it will probably become outmoded before it's changed.)
I bet there are young people that don't use feet or stone. If you don't drink beer, you won't encounter pints very often. (Family-sized milk containers come measures in litres.)
Other than miles, the UK doesn't use imperial measures for anything serious.
Yes, some people talk about their weight in stone or their height in feet and inches, but almost anything official will be in metric.
And yes beer is sold in pints, but in that context it's not really a comparative measure, it's just "a normal sized glass of beer". And bottled beer is usually 500ml these days.
Herewith the part of the Weights And Measures Act (1985) (as amended) that tells you the only two remaining things (as of almost 17 years ago) that can be sold in pints:
Yes? I don't mean to say it's not exact. I'm just saying that when people order pints of beer, they're not thinking about exactly how much liquid that is, that's just what you order.
Exactly. "Pint" and "half" are the local version of "large" and "small".
Bottled beer volumes can vary between 568mL (UK produced), whatever an American pint is for American exports, and 330mL (small bottles), 500mL (large bottles), and 750mL (huge bottles). The metric sizes are common for British produces, as well as the rest of the world -- presumably, standard sized glass bottles are cheaper.
"Contractors are generally not the strongest technically"
Nonesense. Contractors are actually much stronger technically because they usually come in to complete a specific task and are not usually trained by the company.
At least that is my experience here on the east coast.
At least at Google, it was almost impossible to hire an engineer with domain specific knowledge. Nearly everybody we tried to hire who had the domain specific experience our team needed didn't make it past HC due to some BS gotcha question in the interview. On the other hand, contractors were trivial to hire.
So in a sense, the contractors were not "as strong", since they didn't have make it through the absurd Google hiring process. As such, they were generally treated as second class citizens.
Upvote because that is a neat line and I laughed! :)
Also comes with a solution for the AI threat. Ship all AI computers to Mars and let then colonize it! Organic life seems useless to AI, it is a easier path to grow on a dead planet, with no atmosphere to filter sun energy.
sama can relax now, we just solved the AI threat problem. :)
" I would also consider the effects that knowledge of an explored-but-abandoned acquisition would have on your employees' motivation if they found out"
No. First, every kilogram we send to Mars will be hugely expensive, so low mass will be prioritized over long-term sustainability for research and exploration missions.
Second, the plants chosen for bottle gardens are very sturdy and tolerant of non-optimal environments. Humans are a lot more sensitive.
If you're interested in the topic, read "The Martian" by Any Weird, a very well-researched SF story about an astronaut who gets left behind during a Mars mission and has to survive for several years using equipment that was only specced to sustain the expedition for a month.
Thanks for the recommendation, looks like a good read. Although I was a little disappointed when I found out his name was actually Andy Weir, not Any Weird :P
It's been proposed countless times, there are numerous challenges to overcome and the benefits are hard to convince people of.
There's also the issue that it will cost tens or hundreds of billions of dollars to put people on another planet for an extended period of time.
Elon Musk wants to put thousands of people on mars [1] and he's one of the very few individuals with the resources to actually do it successfully. He has had some highly ambitious goals in the past (rocket ship company, electric car company) and has been wildly successful.
NASA supposedly had some funds appropriated to them recently for missions such as researching Mars colonization, they have had plans and discussions of what would be necessary for basic Mars colonization for decades. [2]
