|
Same here, I feel you need all of the above to a damn good one. Else you wither away and DIE!!!
|
|
|
|
|
Don't forget common "logic". Meaning: be able to order the steps of a solution and do the first step before the second step. And be able to see the difference between cause and consequence.
That may be part of "intelligence" or "problem solving capability", but need not be.
|
|
|
|
|
Going into the detail would take pages, but, in fact, what you're saying isn't always true.
I was working on work-flow management and set it up for a purely data-driven methodology. It would deliver work to a persons desk when the information necessary & sufficient to do it was available.
It turns out, when done correctly, that one needs not give any order to any steps in a process. The availability of data does that for your - and process can run in parallel, sequentially, or whatever without any problem. New steps are automatically in their right position based upon nothing more than their data requirements.
Even the order of doing work is an abstraction that need not be define beyond "do it when you can - and not before".
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
First you need knowledge and skill in a specific technology, or you won't be able to do anything (why wasn't that rated 5 out of 5 by everyone)?
After that it's communication. Too much bad code is written because of communication failure.
Communication, whether it's with a customer, your manager, or your coworkers, can make or break a project.
The best teams are teams that communicate.
Unfortunately, many people don't see it that way
|
|
|
|
|
Don't quite agree with you here. Every now and then I have to learn a new technologies with very little time to do so. To me, being able to learn something very fast is key. Having prior knowledge of a technology is an advantage, not a requirement. (Check the next software development job that is posted on you intranet)
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
I never said learning something quick isn't important (I rated it 4/5).
But when a team communicates you may find that learning goes even quicker.
Development is more streamlined.
Specs are clear (or at least you're clear on what's unclear).
You can't build awesome applications by "quickly learning a language" though, intimate knowledge is required.
|
|
|
|
|
I agree with the communication part being important and also the skills. It is the knowledge of a specific technology where I somewhat disagree. That is not as crucial in becoming a developer. The knowledge about technologies you usually learn on the fly.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
So you're building a C# application, who would you rather hire? A C# specialist or someone who'll "learn on the fly"?
You know you can't learn an entire language in a week or two, especially the hard bits that you're going to need for complicated applications.
I'm mostly a C# developer, so sure, I can learn the Entity Framework or WCF or ASP.NET MVC on the fly, but please don't ask me to build a production ready enterprise application in Ruby or Python (I'd learn them quick enough, but the first code wouldn't be pretty or far past the deadline!).
I think that in order to become a good developer you'll have to get down and dirty with at least one language and get to know it intimately. The more the better.
|
|
|
|
|
"Skill refers to a person's expertise or knowledge in a particular field"
"Technology is the collection of techniques, skills, methods and processes used in the production of goods or services or in the accomplishment of objectives, such as scientific investigation. Technology can be the knowledge of techniques, processes, etc. or it can be embedded in machines, computers, devices and factories, which can be operated by individuals without detailed knowledge of the workings of such things."
If I hire someone I would want them to be a c# developer fresh out of university or a specialist depending what I need them for. To have an expectation on someone being adept in the technologies I have is a bit of a too big expectation.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Sander Rossel wrote: So you're building a C# application, who would you rather hire? A C# specialist or someone who'll "learn on the fly"?
Read the survey question again:
Which traits are important if you wish to be a developer?
Your point is far more specific. If you wish to be a developer in general, knowledge of a single discipline is not critical. Nearly everything else on the list is more important, especially learning ability (to learn new disciplines) and communication. I place communication higher in the list as we don't necessarily learn new things every day, but we do communicate within the team, with business partners, with customers, with vendors -- every day. The ability to communicate effectively is a far more useful trait.
Regarding your question, quoted above, my answer is "it depends". I would want at least one C# specialist on the team, but depending on the situation I will want someone with general, wide ranging skills. It also matters if I'm hiring specifically to develop a single application, or if I have needs beyond that application.
If I had to answer blindly for a general situation, would I hire a C# expert whose focus is in that one skill, or a person who is pretty good at C# but has wide ranging skills? I'd hire #2, as I have more confidence that they can learn to handle my future needs.
|
|
|
|
|
Sander Rossel wrote: First you need knowledge and skill in a specific technology, or you won't be able to do anything (why wasn't that rated 5 out of 5 by everyone)? On the contrary - my 'stock in trade' is creating the most generic possible solution for a problem and making in very robust.
The key in all of this is abstraction of a problem: most of the details of a specific technology are just accessorizing.
A solution targeted for a specific technology will be difficult or impossible to expand beyond it - and if, on the other hand, it's supremely extensible then the specific knowledge wasn't the key at all.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You can only implement generic solutions once you have intimate knowledge of a technology.
If you're using C# you're going to need interfaces, base classes, generics, certain base classes, choose the best framework.
If you're using JavaScript you'll better know about prototype, constructor functions, scope, lots of libraries, your package manager etc.
I've never seen someone build robust, extendable, and readable applications in a technology they weren't familiar with.
|
|
|
|
|
We’re talking at cross purposes as to the meaning of ‘technology’ – I am not considering the language utilization as technology. That’s methodology. A problem can be solved by many routes with many languages. My view of technology was that it referred to the actual ‘mechanical’ problem (mechanical used rather loosely).
I honestly don’t know how much of the business works where I work – and my applications are running half the place. They just don’t care, when they do their job, about what it is. I freely admit to them that there are many more technically proficient programmers out there (your meaning of technically) – but not mean who can solve problems as efficiently.
From your perspective, I would certainly admit that I couldn’t write much of a book in Pashto without familiarity with the language. But the books conception is independent of how much of the language I know – just as long as I know enough to express my meaning.
Since our semantics differ, we’re neither in any particular agreement or disagreement.
It goes like this: Aut inveniam viam aut faciam
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
In that case, your meaning of technology is pretty much my-meaning-of-technology-agnostic.
I agree that being able to see the big picture is very important, without any programming language or framework in mind.
I've seen code like if (car.Type == "Volvo") {} else if (car.Type == "BMW") {} else if (car.Type ==... Clearly the programmer is missing some bigger picture!
That's pretty language agnostic, but you should still be able to implement it in the language you're using
|
|
|
|
|
Yet I'm beginning to think my new boss doesn't want creative and curious developers.
|
|
|
|
|
The worst code I've seen was "creative" code.
We have best practices for a reason, don't go and make something up.
Only a few very intelligent people (who know all about the "rules") can write creative code and get away with it.
Curiosity is nice, but a razor sharp focus and the ability to become really good in at least one language/framework is far more important.
After all, curiosity killed the cat
|
|
|
|
|
Creativity is fundamental when working in high technology enviroments - which most business and web environments are not. Creating algorithms is not a question of "best practices" (although there are mathematical and computational properties to be kept firmly in mind) but of creativity. Linking together different algorithms to perform complex operations in set time constraints - there is no best practice there, only unexplored wasteland.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
If a coffee bean is between the Earth and the Sun, is it a Java Eclipse? -- Sascha Lefèvre
/xml>
|
|
|
|
|
I find it sad that knowing frameworks is more important than having good ideas.
|
|
|
|
|
Frameworks come and go. A good brain is there to stay*.
* If properly maintained.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
If a coffee bean is between the Earth and the Sun, is it a Java Eclipse? -- Sascha Lefèvre
/xml>
|
|
|
|
|
I call that knowing the basics.
I know OOP, that's not creative, it's also not a language or a framework, it's basic knowledge.
Knowing basic concepts make it easier to use new languages and frameworks as they come and go, but at the end of the day you need to know one or two to create an application.
|
|
|
|
|
Yeah, but how many developers need to think of good ideas?
Other people think of good ideas, CEO's have ideas, managers have ideas, customers have ideas, consumers have ideas.
Programmers implement ideas. Using technology. Which they should know intimately (or you'll get some bad implementations).
And even IF a programmer has a good idea (a programmer once though the world needed Linux, which turned out to be a pretty good idea) he needs the technical skills to make it reality.
And technical skills come down to, yes, knowing a language and probably one or two frameworks.
|
|
|
|
|
Sadly, you've limited the concept of creativity to the least important aspect for a programmer: coding (as in style).
Creativity has to do with coming up with solutions - it is part and parcel to problem solving. Indeed, inseparable from it.
Without these I'd be quite unemployed by now.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Most solutions boil down to what has been done before.
Imagine having to re-invent the wheel every time!
Every time I've seen programmers get creative there was a (better) out-of-the-box solution already available.
For the record, I don't see implementing some pattern, applying some algorithm, or using some framework as creative. That's simply doing my job.
|
|
|
|
|
I agree with Sander in that creativity is often misplaced in development. Every now and again there just isn't an out-of-the-box solution and that's when the light-bulbs need to go on, but it certainly isn't a day-to-day requirement.
Is creativity an important attribute in a developer? Not really, I think it's certainly possible to be a damned good developer without having a single creative bone in your body.
Really speaking, what we do is craft not art and I'd put it somewhere in the "1% inspiration/99% perspiration" ball-park.
|
|
|
|
|
|