there is the need for the implementation to actually make use of invokedynamic, otherwise there would be no gains. As for clojure:
http://news.ycombinator.com/item?id=2928285
He is missing the point that mostly, people set themselves up for getting feedback, or not. Especially in a leadership position, one can actively create a feedback culture or a "yes men" culture. I'd even venture to say that good leaders can be identified by looking at how well they encourage and use feedback.
On a related note, if his rate is only 70 to 30 with regards to people who receive his feedback constructively, there is still room for improvement. From reading the article, it seems to me he might be little blunt every now and then.
On the latter point, I think you also need to cultivate some sort of trust relationship. People need to care about your feedback, and truly believe that your view might be better than the view they were holding. Just giving blunt feedback is an easy skill that everyone on Reddit has, so I think people are pretty used to tuning it out, especially if you give them any reason to attribute it to you just being grumpy/biased/jerkish.
One part of this, imo, is that the feedback-giver has to accept that they might also be wrong, and be open to admitting that their feedback was misguided or a matter of opinion if it turns out to be. That helps people to believe that it's not just the feedback-giver trying to impose their personal opinions, but actually well-considered advice.
I wish I knew how the Googles and Facebooks hire a crowd of junior programmers and have them do these amazing things.
I am in the 5th year of leading development teams and have more than 5 years to go until my half-life is over. Yet, I have not figured out how to run a team entirely of junior programmers. Yes, they come with a lot of energy and current knowledge but there is also so much missing that people gain from, well, experience. In the field of software but also in all the adjacent domains that are so crucial for being successful as a team.
I cannot image how I would do without having a few senior people around who can give things a little structure and a little broader understanding of things.
Also, most experienced folks, even if not super up-to-date with fancy technology, are a hell of a lot more productive than the shooting-from-the-hip youngster. They don't need to put in 12 hour days.
My other problem is that it's so hard to actually find good senior programmers. There are also a lot of people who got stuck more than ten years ago ...
My experienced as an unofficial team lead of a few programmers with various experience (which I conclude that they were Jr. Programmers with a few years of lack of mentorship) was to do the following:
1) Define structure
Set some rules. Coding styles, check-in etiquette
2) Find tools to limit mistakes
Static code analysis, automate build that breaks when #1 fails.
3) Always on alert
Do a lot of code reviews. A lot. Argue and fight over little things (variable naming convention, missing documentations, unclear code).
Now this might not sit well with others so get ready:
4) Become a "drill" sergeant
I find that becoming the "bulldog" sometime works. You've got to become some sort of "drill" sergeant. People may dislike you at first but if the project is successful, they can hate you all the way to the exit door all they like.
That was my experience. I made a concious decision to put the success of the project as the top priority. Even if it means breaking some bridges with other programmers. I hope they learn why I did those things in the future. If they don't, I won't quarrel or regret my action.
5) Be nice on other occasions
I may be the biggest jerk during code-review and check-in commits but when my co-workers stuck, I'll be gladly help them even if it means I have to sit with them and do my overtime. This can gain you some respect after confrontation/intense debate/being a jerk.
I always try to be friendly during office/release party. Give credit to the team, etc.
Just an alternative to #4 (which I have been on times with various degrees of success).
What's the #1 thing people are afraid of? Public shame. I have a theory that Scrum primarily works because of this. Just have daily Scrum-light meetings with your group. If you have 15 minutes with a group of 5-6 people and everyone has to say either "done" or "not done"... the not dones will of course have some silly excuse, but because of the time constraint you must cut them off, be curt, and say to the effect "so John can you help Dan with that right after we break?". And then everyone would make commitments on to what they would do that day. I guess in a way you can say this was being a drill sergeant, but the thing was I wasn't an a-hole, that 15 minute meeting every morning was just part of the process, it was expected.
After a few weeks of this everything moves at twice the speed. I had a team of 6 devs (including myself) burn through nearly 200 bugs in 2 months. That's every engineer fixing about 4 bugs a day. There was a hug chasm of talents on that team... we had the top guy in my dept as well as one of the weakest engineers on the same team. Everyone performed.
Nice list! That is pretty much what I am expecting of myself and other more senior developers.
I guess, I am not a super good "drill" sergeant, though. All I can do is leading by example, mainly doing a lot of pairing. But that is time consuming, so I might try to develop more of a sergeant attitude.
> I wish I knew how the Googles and Facebooks hire a crowd of junior programmers and have them do these amazing things
Volume. You are forgetting (and/or haven't been privy to) all their failures. Statistically if you do 100 things 1 or 2 of them will be amazing, the rest are crap. We've seen publicly a few of those companies' failures. I'm sure there are many more we haven't.
They haven't managed jr devs any better than the rest of us. They just brute forced it with shed loads of money and people.
>> it's so hard to actually find good senior programmers
Most of them either find jobs through referrals, or have become consultants in order to avoid the unwritten rule in many companies that you can't make a higher salary than your manager (yes I know there are exceptions).
The junior programmers I worked with at Google were far better than the senior programmers I worked with at other jobs. Experience has value, but it's not the only attribute that matters when it comes to skill and ability. Taking the best kids out of MIT, CMU, and Stanford is a lot different than the junior programmers you'd encounter at most places.
I don't know about Facebook, but Google doesn't seem to be hiring many college kids these days. It's hard to find a 22-year-old with both the skill and desire to work in Google's main languages (Java and C++). Also, what you said is quite true: a team consisting entirely of junior programmers is difficult to manage.
I found the hardest part to be the impatience :) But then one has to be fair and look at one self at that age and acknowledge that one was just as much a pain in the ass at that age. Karma pays forward.
I disagree to reduce programmers to geeks that only have fun when there is a ton of new technology and a fancy feature that only they like.
Most people I've worked with have fun when the project goes well, customers are happy and the like.
A really post-mature programmer understands the values behind so that he does not need rules any more.
Well, no organization should complain too loud if it is not valueing the IT department as much as it does its profit centers. The situation in the most companies is that IT is trimmed as cheap as possible, so what do people expect to happen??
Also, for some reason, IT departments seem to get or develop goals that are not aligned with the business. In my current place, IT is actually actively working to make the life of R&D departments harder. It's not even the question how to create a secure environment in which people can still do more than Office and Email.
I use Ruby a lot and love it! But one should be fair and take into account that it has had much more time maturing. From what I can tell, it is plateauing right now. On a high level admittedly.
Instead of concluding that Clojure is not the right language, I'd rather say it is a niche language right now. With great potential to become an awesome mainstream, general purpose technology long-term. After all, it has some features and applications that Ruby will never get.
But is it fair at all to compare two languages with a different paradigm?
I am a bit suprised to not see TDD or any of its siblings being pulled into the discussion.
To me, the better someone is doing TD, the better the code communicates because TDD makes you think about the right things when coding. It sets your priorities straight.
So the question of n00b or vet for me is just how well someone does TDD. And there is also this great book by Kent Beck about Implementation Patterns that is all about well-communication code.
Interesting.
I am no entrepreneur but lead developers at a large corp. My scheme is to pick the battles. Usually not the small ones.
I always thought entrepreneurs would do it likewise, their pressure is surely even bigger.