A great engineer pushes technology forward and leads, a good engineer stays current and keeps his company in good technical standing, and bad engineers make excuses and rest on their laurels.
In a field which is not regulated and where tools are not standardized, how do you know if the greatest and latest tech is actually any good?
The fact is there are a lot of jobs out there where you can't really be great at them and still have time to be a decent parent, these things range from being special forces to being an olympic athlete, and yes, being great at programming is one of these things. There's simply too much to learn and it's changing too fast to keep up if you cannot be entirely dedicated to it.
The job title of "programmer" (and its variants) covers a large number of different actual jobs and fields. What you've said is not true of every programming job out there.
You end up recognizing that there are different types of programming jobs, in your final paragraph, but I wanted to emphasize it.
The need for "constant technical learning" can true for example, if you work as a consultant, and are placed in different projects, with different technologies, every x months. It is also true if you want to change jobs with some frequency. In those situations, being able to to work, from the get go, with several different technologies is a plus.
But a lot of programming jobs are not novelty technology based. For example, if you work at a company which develops products (instead of services) or at a company that does some in-house development as means to support other business areas, you'll find out that the company as little (or no) incentive to change. Also, in places where the focus is in the domain knowledge, people put way more value on that domain knowledge than on knowledge of technical stuff. These companies may decide to update their technology, or adopt a new complimentary technology as they expand their products, but, with that, typically comes company provided training.
The fact is there are a lot of jobs out there where you can't really be great at them and still have time to be a decent parent, these things range from being special forces to being an olympic athlete, and yes, being great at programming is one of these things. There's simply too much to learn and it's changing too fast to keep up if you cannot be entirely dedicated to it.
The job title of "programmer" (and its variants) covers a large number of different actual jobs and fields. What you've said is not true of every programming job out there.
You end up recognizing that there are different types of programming jobs, in your final paragraph, but I wanted to emphasize it.
The need for "constant technical learning" can true for example, if you work as a consultant, and are placed in different projects, with different technologies, every x months. It is also true if you want to change jobs with some frequency. In those situations, being able to to work, from the get go, with several different technologies is a plus.
But a lot of programming jobs are not novelty technology based. For example, if you work at a company which develops products (instead of services) or at a company that does some in-house development as means to support other business areas, you'll find out that the company as little (or no) incentive to change. Also, in places where the focus is in the domain knowledge, people put way more value on that domain knowledge than on knowledge of technical stuff. These companies may decide to update their technology, or adopt a new complimentary technology as they expand their products, but, with that, typically comes company provided training.
I'd call someone current who has 5 years of all of these: Objective-C & MAC/iOS experience, C#/WPF, Android 4.1, SQL/SQLite/Oracle, C/C#/C++, Java, Python, Javascript, HTML,
Are you joking? Or are you using a loose meaning of the word "know".
People need to start being realistic with this "keeping up" stuff.
Let's take a look at the stuff you listed and where they are typically used:
1) web - Java; Python; Javascript; HTML;
2) mobile - Objective-C & iOs for iPhone; Java for Android
3) desktop - C#/WPF; Java; Objective-C & iOS; C/C#/C++
You just described three different development roles (although there may be some intersection of technologies).
Let's say I'm working as a full time as a "desktop developer" in a company product where I work with a Java development stack. Do you think I should spend my free time doing web development and mobile development , in order to be considered "current"?
Which other professions have these kinds of expectations?
I like code reviews and think they can work. Here's some anecdotal evidence:
I work at a company where the "code review" is part of the process, but not all teams end up doing it (i.e. for time constraints). Specifically, there's a smallish team who mostly does not do them.
This has given me the opportunity to see the result of work done with "code review" and and work done without code reviews, by people in the working same environment, hired under the same (or similar) criteria.
In summary, there is a significant difference in code quality in the code written by these folks who usually skip the code reviews. Sometimes these guys work on code that's under my team's irresponsibility and we end up having to cleaning it up (to the point of rewrite).
If these people would do regular reviews, and talk about the code, and what makes it good or bad (this usually happens in a code review), their code would eventually improve. I know my code improved a lot by being reviewed by my colleagues.
The code review allows for some knowledge passing, and is also a quick "code readability" sanity test.
On the occasion that something is caught, it could also be caught at lower cost with other methods. Inspection is not as effective as testing so delaying testing for inspection is ignorant.
Its been publicized that the cost of correcting a bug goes up with time (i.e. its cheaper to fix a bug that is found in the development phase, than if it is found in the QA / testing phase; its cheaper to fix a bug found in QA, than a bug found by the client). I think I first read in the book "Code Complete".
Code quality issues are not caught up by the QA / testing people.
The worst code I have ever worked with has come at the job I've had for the last 8 months. It is all formally code reviewed and it clear that code review is the lowest value work that the programmers produce.
If your code reviews are not improving the code, maybe the process is not a good one. Maybe you want to share how you guys do it?
I think software patents could be fine as long as they are specific to a SINGLE IMPLEMENTATION of an algorithm or idea. If your patent was implemented in C++, then the same algorithm implemented in Perl or even COBOL SHOULD NOT BE COVERED.
In some cases, translating from language-X to language-Y is a straightforward line-by-line-with-a-few-additions conversion. The patent would not be of much value since anyone could just use the reference implementation and translate it to very-similar-language. This would possibly mean that the original "inventor" would start patenting the same algorithm implemented in sevaral programming languages, as long as the conversion is simple and/or has little cost.
(And I'm not defending the patents system.)
or my own free book [lightandmatter.com]
Just to say thanks for making those textbooks freely available
Best Regards.
I was not saying that Unit Tests cover everything. I was just saying that doing them raises my enjoyment of testing... I still do other kinds of testing and so does the company's QA team.
The same is true in the company I work at, which develops products related to resource planning. Most managers and team leaders of my department are both managers and coders. They have a lot of valuable knowledge.
Domain knowledge is essential because it makes you more valuable. Specially if the products are complex, since the new guy will have to receive a lot of training before he can become useful.
If you work on generic applications or websites where you only need to know technical skills (like a Programming Language + SQL) you are easier to replace with a younger guy.
"I'd rather write half as much code, spend half as much time debugging it, and go home. "
Thats why I like Test Driven Development: when I'm writing unit cases, I'm doing test case design AND I'm coding. Then I also get to write the code that passes the tests. So I end up enjoying the testing part of the work a little more.
Some people carve careers, others chisel them.
