With all due respect to the author, it's not what's described in the article:
1. Always do it the right way: Well, what's the right way?
2. Be willing to suffer: You can suffer a lot and turn out absolute crap. In fact, if you turn out absolute crap you most certainly will suffer.
3. Never stop learning: You can learn all the trendy new technologies and still be mediocre in all of them. In fact it's common for fanyboys.
4. Lend a helping hand: It's common for mediocre programmers to spread disinformation on their blogs.
5. Take your time: And you can be slow doing it!
As I said, in my opinion software engineering is about discipline. You can do great stuff in any language, C/C++/Pascal/Java/Python/whatever, whether you use SVN or Git, whether you're on a Mac/Windows or Linux, but you have to be disciplined. You have to be patient enough not to start coding like a monkey and do come research before. I've known engineers who will do weeks of research before writing a single line of code, driving everyone mad, but proving themselves right afterwards. You have to be patient enough to think about your code before you write it, follow best-practices and some conventions when you write, constantly re-factor you old crap, write good comments, write Makefiles, etc. You have to be disciplined enough to do testing, have a test environment and a deploy workflow. Write proper documentation (if required), write commit messages, and so on. Engineering is not science, so you don't have to invent the wheel, it's also not art, so you don't have to be super-creative, but you have to be smart enough to be disciplined in the old-school IBM way.
My dad has no background in IT at all. He once was appointed to lead the Operation division (everything including IT). He saw that the systems his bank used was buggy and spent a few days figuring out how the systems worked (flow of the systems, input, output, users, etc).
He found the problems eventually. His solution to the CEO? The IT team should be discipline in almost every step they execute. Discipline in terms of execution, discipline in terms of documentation, discipline in terms of logging information, etc.
Agile, SCRUM, or whatever new methodologies out there (including CMMI) directing engineers in the software industry specifically to be more discipline. Feel free to talk bad/negatives about CMMI, but the intention is to figure out what went wrong and how to not repeat the bad experience (describe in each level).
In Agile, process is not equal bureaucracy. Process is equals discipline. - Eric Ries
UNIX/Linux philosophies teaches software developer to be discipline.
Google has a set of coding/commit rules, rigid structures regarding their source code (code review, etc) because they knew if things were not in certain order, chaos rises.
In Agile, process is not equal bureaucracy. Process is equals discipline. - Eric Ries
This is false. Agile is total bureaucracy. From "no code without passing tests" to "pay $1 if you're late to the standup meeting", Agile is about everything but writing software that works.
When I think back to "Agile" jobs I had, I can remember our team spending about 4 months writing 3 files worth of code that did basically nothing for the application as a whole. We did have a lot of meetings and tests, though.
Conversely, when I think about code I've written on my own without any structure or rules, I have over 100 completed projects/libraries in a few years of hacking. And when I think about code I've written for non-Agile jobs, the amount is the same -- lots of reliable, finished projects.
Agile is a way for the bad programmers to slow down the good programmers, so everyone can feel better about themselves. Avoid.
UNIX/Linux philosophies teaches software developer to be discipline.
How? When I write a Windows application, I have a full-screen Emacs with my code, a compile buffer for builds and tests, and a ghci (etc.) buffer. When I write a UNIX application, well, it's exactly the same.
If you're discipline enough with your time, you shouldn't worry about things like this. Life is not perfect, there will always be small things that might bother you but not other people. Take it easy, besides, like I said, if you're punctuate, why does it bother you much? maybe it is meant for your co-workers that have time-management issues.
> "No code without passing tests"
I've worked with smart people with big ego swinging their code like the best thing since slice of bread. I've worked with smart people who think they can solve everything by raw-talent. I've worked with smart people but not careful. In every situation, forcing TDD help to store "order".
People out there seems to echo the same story. Now here's the thing, what should I do? should I accept your story and have blind-faith on the new guys? Thinking that they're smart and all that and no unit-test?
Should I trust someone that say "I designed my code to be unit-testable, but I have no time to write unit-tests"?
How many allegedly "good developers" out there that my company can afford to pay? Market also determines the price and right now the price of junior developers are quite high.
And one more thing: I respect your skill for having over 100 projects over a few years of hacking. That's great. There should be more people like you, and less number of failed projects out there. What I'm trying to say is that the statistics (Standish Group) isn't on your side.
TDD is a topic that would always caused a disagreement with a group of programmers who have "success stories" without TDD, open source projects where there are no deadline and have millions contributors (well, eventually the bug will be fixed right... eventually... someday).
If you're advocating things like TDD or fixed daily meetings, you should perhaps avoid using words like "statistics". They most certainly are not on your side; indeed, there is very little evidence that these trendy Agile-based processes provide any benefit whatsoever.
I'm not sold completely on TDD. Part of me think that TDD is a necessary evil. Some organizations have the resources to hire many QAs that might help to reduce the number of unit-tests. I'm not saying that is the most cost effective way to go.
Also, if the programmers words can be trusted (that their code is unit-testable, instead of highly-coupled, lots of dependency cycle, etc), writing unit-test last would be alright as well.
FWIW, I think the most important thing here is not to confuse use of unit tests with the adoption of TDD. The former does not imply the latter: you can write unit tests after you write your code, or even before/during writing code for that matter, without being test-driven in your approach.
I have yet to see any credible study that showed a benefit for TDD and controlled for the use of unit testing as part of a more traditional development process. There is some evidence that, at least for some types of project, TDD has been more successful by some metrics than a heavyweight, waterfall process with no unit testing, but there are usually so many uncontrolled variables involved that it's hard to read much of value into any of those results.
The basic tenets per the Agile Manifesto are reasonable enough, and don't imply any of the silliness you described.
Equally, the incremental style of development shared by all Agile processes has always been a better idea for most types of project than having some huge spec up-front and then not talking to anyone about it for six months. This was true long before anyone coined the term "agile" to describe the idea.
Of course, if you choose to adopt something like XP as your process, then you go a lot further. Personally, I consider XP a rather silly idea, because its basic principle is flawed: just because doing something can be helpful, that does not imply that doing it religiously all the time is better.
Likewise, the basic idea underlying Scrum is to have a prioritised list of stuff you need to get done, divided into practically sized chunks; to do a small number of them to make your next release that does more useful stuff than the last one; and then to repeat. Again, this is a sensible enough idea, and something that a lot of projects have done for much longer than the name "Scrum" has been around. It's only when you start adding on bucketloads of meetings and strict deadlines and people with silly job titles that it becomes rather comical.
These problems with taking basically good ideas too far are not Agile's problem. They are just what you get when consultants smell book deals.
> I am saying that you should try to accomplish the task on your own first, and if you get stuck, then ask for help. Don’t simply ask for help every time without first trying to solve the problem yourself. Chances are, you’ll find that you could have figured it out on your own once you know the answer.
If you're a junior engineer and are working with and older engineer you respect. I highly recommend you try to solve the problem, make a start at it, and then ask your mentor what they think of your approach at lunch, on break, or at the end of the day. This gives you most of the benefit of actually implementing something while saving you most of the pain of having to maintain your mistakes.
Yes, this is a good idea. I think you can get 90% of the way there on your own though, by asking yourself a few questions. Does it work? Am I sure it works? Will I be able to replace this code with new code in a year without touching anything else?
By the time you've answered "Am I sure it works?", the answer to the next question is almost always yes. If you can test something enough to be sure it works, it's probably modular enough for your application, too.
Communication is important enough to have had it's own section. Communicating to future maintainers through code, comments, tests, and documentation. Communicating designs, ideas, issues with team and leaders. Communicating everything with designers, customers, testers, and stake holders.
A good engineers are good individually. Great engineers work with and elevate the team(s) they are part of. In military parlance they are force multipliers.
Always do it the right way? What way is the right way? The right way from an engineering standpoint or a business standpoint?
In my experience the right engineering way and right business way are often at odds. My boss just says I'm 'developing under protest' in these situations. :)
There's one thing that's missing from these kinds of posts. Usually, they describe a set of characteristics of great software engineers. However, you have to be careful not to confuse that with the set of characteristics of a great programmer.
Your contrast between "software engineer" in one sentence and "programmer" in the next is interesting. Did you mean to imply that there really is only one set of characteristics that define a great programmer, or were you assuming that software engineers and programmers are the same thing? (I disagree in either case, but I'm not sure how to parse your post to debate the point you intended to make.)
In that case, let me suggest as an alternative that a common problem with these posts is that they only consider characteristics of programmers. The difference between being a mere programmer and a software engineer (at the risk of offending real engineers who earned that title) is the way the engineer runs his or her project, from capturing and interpreting the customer/client's actual requirements at the start, through to QA, deployment and beyond. Writing a program is hard, but writing the right program and being sure that it actually works is even harder, and herein lies the difference IMHO. That all said, this particular article doesn't fall into that trap, so I'll leave it there.
With all due respect to the author, it's not what's described in the article:
1. Always do it the right way: Well, what's the right way?
2. Be willing to suffer: You can suffer a lot and turn out absolute crap. In fact, if you turn out absolute crap you most certainly will suffer.
3. Never stop learning: You can learn all the trendy new technologies and still be mediocre in all of them. In fact it's common for fanyboys.
4. Lend a helping hand: It's common for mediocre programmers to spread disinformation on their blogs.
5. Take your time: And you can be slow doing it!
As I said, in my opinion software engineering is about discipline. You can do great stuff in any language, C/C++/Pascal/Java/Python/whatever, whether you use SVN or Git, whether you're on a Mac/Windows or Linux, but you have to be disciplined. You have to be patient enough not to start coding like a monkey and do come research before. I've known engineers who will do weeks of research before writing a single line of code, driving everyone mad, but proving themselves right afterwards. You have to be patient enough to think about your code before you write it, follow best-practices and some conventions when you write, constantly re-factor you old crap, write good comments, write Makefiles, etc. You have to be disciplined enough to do testing, have a test environment and a deploy workflow. Write proper documentation (if required), write commit messages, and so on. Engineering is not science, so you don't have to invent the wheel, it's also not art, so you don't have to be super-creative, but you have to be smart enough to be disciplined in the old-school IBM way.