Newtopian
For Allo-Stop yes there was exchange of money but the amounts were such that it would be barely more than the split expenses for gas for the trip.
Wonder if this will be allowed, seeing how Uber is being forced to get taxi licences and such for it's drivers, I doubt this will go very far around here.
Each task has it's set or preferred tools, to write a quick command line tool to bridge a gap between two systems and automate our workflow a bit further python is just perfect for me and much more productive than C#. However to create a system with a team of dozens spanning the whole skill gamut I feel much more comfortable having the compiler as an active member of my team policing the architectural vision for us. In which case C#/Java will win hands down.
If however speed and responsiveness are prime worries then I'll roll up my sleeves and bring C/C++ in. sure my productivity will take a hit, it will likely be harder to maintain as well but if this effort makes the difference for my customers in their productivity then it's well worth the investment.
Often times the final system will be a mix of all these technologies, each used where it's strength shines to maximise their impact.
Yet the technology is worthless when faced with inadequate code structure and system architecture. Coupled convoluted code will be a PITA no matter the language used.
where X is any number of lines necessary for implementing the ONE thing that function should be doing
Any attempt to replace X with a concrete number will invariably sacrifice simplicity for the sake of that number.
I guess then it's ok to put one below...
vs
Are two very different indicators. And both are, least in my mind, equally important. One measure the holistic approach to source code including everything necessary to produce a functional system. Checkout, build, use.
The other is a measure of how much care is given to the overall process of software engineering. How much automation the tests receive, how much attention is given to deployment etc.
Software construction must be tied intimately with the software code itself for thousands of good reasons. Too many times have I seen a team jump onto the CI bandwagon; abandoning all notions of build scripts to let this new shiny thing perform it's magical incantations to build and package the system. A checkout alone is no longer sufficient to gain a fully functional system one can test locally, the CI becomes in an integral part of the software code but without the process the rest of the code receives (reviews, versioning, source control etc).
With the multiplication of commercial tools flaunting how easy it is to automate all this that one does not even need a programmer anymore, I fear software construction will become harder and harder to do without the help of these external systems.
So yes, do team have a single operation to build (that is construct) a workable system is still very much relevant.
And yes, do team use continuous integration to automate their test and delivery process is also important.
What recourse one has to proove wrong some top-secret algorithm once said flag has been raised ?
Paranoia is extremely contagious and often countered with more paranoia.
Best I can explain this is from a personnal story. I used to do rollerblade... I mean a lot of it. It was my main mean of transportation ans I could do easily 20-50km per day. Obviously after a year or two of this I got pretty good and many of my friends would ask me to teach them how to do it. And I did, relatively well, they got the hang of some subtelties of breaking and turning.
However, I noticed that as time went on, I found it more difficult to teach it. It got so natural for me that decomposing the movements in their atomic parts was difficult.
I cound identify two factors that contributed to me going from a decent teacher to a lousy one while at the same time I went from a decent rollerblader to a pretty good one.
For one, the abstraction went from a concious one to a subcouncious one. I no longer had to think about doing it right, I just did. Second I had not taught anyone for a while, so I did not keep in touch with how I built these abstractions in the first place. Both together contributed in me forgetting how to build these abstractions.
To teach one does not have to be a foremost expert in a field but just ahead of the target audience to be in control of the material they need to absorb. The greater the difference in knowledge between the target audience and the teacher the harder for the teacher to "bring down" his thaught processes to their level. That is unless you 1 - were teaching the whole time between getting from pretty good to expert. This way you've kept contact with the different steps and breakdown you'va had to go through yourself while learning. Here is probably where most have had their bad experience when an expert tried to teach them but miserably failed at it. 2 - are a natural pedagogue, in other words you are a genious at making things around you look simple. I think Richard Feynmann would be an stellar example of this.
That being said, as a corrolary to point 2 above, there are people that are just bad at teaching reagardless of any other factors.