|
Adding to this, the real gift is the ability to let go of the difficult problem enough to come up with "novel" solutions, like:
- FastBack: Don't let the floppy drive spin down (drastic reduction in backup times)
- NCD: Store the directory structure in a file for quick referencing
- Tape Error: Realizing that we did not have to do more than 6 lines of code to handle a tape error during an update, because we could actually just skip all "deletes" (missing records) until we got our first add/update (meaning we resynched naturally).
- Modified Binary search to find the "First" item in list with duplicates (fun/easy problem)
That is what is truly amazing. Twisting a problem (Binary search) into a solution that creates a better solution than originally intended.
There seems to be a "tipping point" where every obvious solution to a problem is UGLY, until a viola!
|
|
|
|
|
I think I get stuck in the "ugly" stage - heard-headedness + OCD is not fun at all
But yes, when you can push through it becomes a thing of beauty
|
|
|
|
|
|
S.. as a Service, Yes!
|
|
|
|
|
You forgot an option:
a good vocabulary in swearing (at your computer)
|
|
|
|
|
At the end of the day, we are paid to solve problems and deliver. Everything else is means to that end.
|
|
|
|
|
Right. And the question is which of those means are important to achieving any given end (multiple choice).
|
|
|
|
|
The skills needed to be a web developer and the skills needed to write a compiler are vastly different, and so therefore you would expect the skills to likewise differ too. To lump the skills for every developer into one big melting pot therefore doesn't work. Whilst there are skills that are common to both, there are also skills that fit more readily to one role than another.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I think your core "basic" developer traits will suit you well no matter what niche you end up in, the same can be said of the opposite, as well. If you suck...you suck.
|
|
|
|
|
I agree that some traits are transferable across development disciplines, but certain traits are more applicable than others. Creativity for example is (arguably) more useful to a web developer than perhaps a compiler writer.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
That's completely dependent on how you define "creativity", I personally don't limit it to the artistic aspects of page layout or UI development.
In my opinion creativity is one of the key aspects to being a good software developer.
|
|
|
|
|
|
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 |
|
|
|
|
|