askorkin

I write about new things I learn, old things I've forgotten more than once before, opinions on trends I see as well as my ideas about improving the software craft in some way. I submit the stuff I write to 2-3 places to spread it around, I figure that if I found it useful or interesting, other people might find it useful or interesting also.

I don't hide the fact that I submit the things I write, I also don't spend hours trawling the web for random things to submit. Instead I spend my time learning new things, coming up with ideas and opinions, reading and writing stuff in a format that others might find interesting.

I don't ask for votes or anything else from people, if they find what I write interesting they will read it, if not - they won't. By submitting something I give people a chance to read it and trust them to make up their own mind.

You find what I write trivial - don't read it. That's right, redirection in bash, i can't tell you how many times I've forgotten how to do it, and how many other people have as well. It is specific to bash, it doesn't work in other shells, it doesn't work in other OS's, if it did I would have said so in the article.

In this case, I've written something down off the top of my head; no offense but what have you written down lately? I hope that before you go ahead and label other people's work as spam, you will have produced a lot of high quality content of your own that can put all this 'trivial' stuff to shame. That's only fair right?

I am going to assume that your last 30 submissions were of the highest caliber and were all both educational and insightful. I could check of course, but instead I am going to go and learn something new and then write about it.

I agree there is no silver bullet. You may not agree with the article, but it id generate some discussion and got people to share their thoughts (including you :)). This way we can all learn from each others experiences and discover methods that can work for us.

The other reasons can often be more important than programming skills. Programming skills are arguably easier to acquire than people skills.

If you know how an insertion sort (for example) works, then you can pretty much answer all your questions fairly easily. Knowing algos is good, but does not in itself make you competent in every respect.

Having said that, I am not trying to be critical. I completely agree that having a discussion like this is extremely valuable and can let you find out a lot about a person and even eliminate most of the chaff (although I have met a couple of people who I wouldn't necessarily hire, but who could have done well in a discussion like that).

After your discussion, you might even decide you really like a person, but does your team like them? How about this, can you tell if a person can stick to a deadline? A longer discussion is necessary before this becomes apparent.

It is not quite the same thing, but some of the elements would certainly apply, such as confidentiality etc.

thanks for the feedback, much appreciated

Most people I know are more than capable of discussing Agile techniques/practices and writing plenty of code at the same time, the two are not mutually exclusive :).

I have been finding more and more that things which are obvious to some are not necessarily obvious to others. Not everyone is a guru in every skill and everyone has to start as a newbie with all new skill you learn.

What about for people who are not working with Ruby but are curious about how it compares? How about those who have just started working with Ruby and are just learning? Think back to the first time you started reading about Ruby, was all the info you ever wanted freely available and clearly laid out? I am betting no.

This is why these days whenever I learn anything new (or think of something I know really well), as soon as i get it straight in my own head I go and write it up. It helps me clarify it even further for myself plus, since the information is out there it may end up helping others who are learning about the same topics.

Anyway, that's how I feel.

I do appreciate what you're saying, but with this kind of thinking, where do you stop? Yes you can do defense in depth and defensive programming and all sorts of nice things. But if you tried to do this for every scenario all the time, you would never get anything done. At some point you need to trade off being productive against well pretty much anything else, which is basically YAGNI, i.e. do enough but don't go overboard.

Agreed, that is an issue unfortunately.

I believe it all starts with the right people. If you have the right people in your team, i.e. open minded, willing to learn and improve etc., they will naturally tend to perpetuate the right kind of environment. It gets a lot more difficult when you have to start with people who are not necessarily open to this kind of thinking. In this situation you have to first build a whole lot of trust among the team members and management before trying to slowly introduce ideas like this. Often projects finish before such a level of trust can be established.

Thats a great one as well, didn't even realise ps could do that

Oh yeah, now I get the reference :)

Thanks for that, I've been copping flac left right and center even on twitter :)

That's what I meant, (I guess I didn't express myself very well)

Exactly the point I was trying to make

Agreed, but also we not only try to learn from the best, but also try to teach what we know to those who know less.

Ahh, I did not realise, I will do so in future. Thanks for letting me know.

I disagree, even just coming from the perspective of agile practices (rather than agile ideals). I don't see how you would easily engage in test first development. Infact testing in general is a challenge. Same goes for refactoring, you can adjust the model, but what if you're trying to overcome other challenges, such as streamline to make your code more performant. MDA hides all of that away. It is true though that the more people centric agile practices are still valid (retros, stand ups etc.), but these would be valid in any situation.

I agree with you, I suppose I tend to take those things for granted, possibly because I've been fortunate enough lately to work in environments where both 1) and 2) are pretty much a given (lucky me).

Pair programming is an agile practice and in my experience it is a LOT easier to do agile when you have good people on your team, not just good developers, but good human beings.