Reputation
21,797
Next tag badge:
173/100 score
18/20 answers
Badges
7 42 120
Impact
~935k people reached

Jun
9
answered Statistics on time estimates for web application
Jun
9
comment How can you filter out irritable programmers in interviews?
+1 For interviewing the interviewer! Just as often as employers hire bad employees, employees join bad employers. Years of interviewing taught me the right questions to ask and how to interpret their reactions. I have asked about average turnover "Some people need to find an environment they are happy in." WARNING, any answer other than I am not sure should be skeptical. On development processes, "We are trying to go Agile" or just "trying to" anything. WARNING, sign of dysfunctional leadership or management. Probe them about they have tried and why they think it failed.
Jun
9
comment How can you filter out irritable programmers in interviews?
@Ant, I was being interviewed in such a situation where the interviewer attempted this technique and it backfired on him horribly. He presented a code challenge where I was given a Java class and had to write a program to clone an Object of that class. I modified the class to implement the clone() method of type Object. He said I was wrong which I was. I should have declared the Cloneable interface. I didn't see it and said it was fine, but he said my problem was that Object does not have a clone() method which is ALSO wrong. I insisted he was wrong and he got indignant. I walked out smirking.
Jun
8
comment How do you program effectively when it takes a long time to simply test your code?
You "exchange" and "trading" software engineers are a unique breed. My friend had a series of mental breakdowns working for one such company. I never hear good things come out of that niche of the software industry.
Jun
8
comment How do you program effectively when it takes a long time to simply test your code?
We all make stupid mistakes from time to time, they only occur less with time and experience.
Jun
8
comment Should experienced programmers know database queries?
@Anna, yes a VERY different field indeed, I was under the impression that NoSQL databases were still not widely accepted on the business side. I have gone 7 years in my career and not one person I have worked with ever even considered it as a possibility. I must have been negligent. I revised my original answer to be a little more specific.
Jun
8
awarded  Editor
Jun
8
revised Should experienced programmers know database queries?
Being more specific from my original WIDE assertions
Jun
8
comment Should experienced programmers know database queries?
I stand by what I said. Theoretically if the application is tiered and componentized well then there is no need however in my entire professional experience my team and I would have DROWNED if we weren't experts at SQL, even when we had a dedicated team for RDBMS design and development. Perhaps I am old fashioned or just have terrible luck in my career?
Jun
8
comment Should experienced programmers know database queries?
@SK-logic, What kinds of options do you feel make relational databases irrelevant? Datawarehousing is too specialized for analytics to be useful in a transactional system. And don't get me started on everything wrong with OODBMS.
Jun
8
comment Should experienced programmers know database queries?
+1 and I wish I could give you 100 more! I know that corellation != causation but it is more than apparent to me that the most effective application developers I have EVER worked with had a thorough understanding of how to write a standard SELECT query. I should be able to hand a good developer a data model and a "question" about the data and that person should eventually be able to write a query that "answers" my question.
Jun
8
comment Should experienced programmers know database queries?
Would you still disagree if I say that a good ENTERPRISE or BUSINESS application software engineer (as opposed to embedded systems, etc...) and if I said that this person should be an expert at STANDARD relational database queries (without fancy-pants vendor specifics like analytical queries and the like)? A thorough understanding of SQL SELECT statements, all types of joins, unions, intersects and merges, inline views, conditions, ordering and grouping result sets should be thoroughly understood and amply demonstrated by ANY software engineer that carries the labels that I specified above.
Jun
8
comment Should experienced programmers know database queries?
+1 Great answer!
Jun
8
comment Should experienced programmers know database queries?
Maybe my answer is a little too subjective... it depends on you define "complex". To myself, a complex query is one that has an unusual number of joins, or uses vendor specific functionality, OR especially in performance critical queries that must be tuned using vendor specific knowledge.
Jun
8
comment Should experienced programmers know database queries?
@Shamim, I would expect this person to be moderately experienced with queries unless this person was a junior or entry level. Perhaps this person only has a few years experience and was sheltered on a highly specialized team?
Jun
8
answered Should experienced programmers know database queries?
Jun
7
awarded  Nice Answer
Jun
7
comment Does craftsmanship pay off?
+1 On name recognition! This is especially true if you live in a smaller city like I do. If you plan on settling in a smaller city area for a long time you may end up working with certain people again sometime in your career as there is a limited number of large employers in the region. At one place, one name came to notoriety amongst me and my peers, someone who used to work at the company who wrote the legendary 15 level nested loop. Later in my career his resume came to my inbox, which I recognized immediately and tossed.
Jun
6
awarded  Nice Answer
Jun
6
comment Is there a source for user opinions on commercial enterprise software?
They don't have to win in court, they don't even have to have anything remotely resembling a case. They will crush you in legal fees the way the US crushed the Soviet Union by outspending.