4 ms·
Discipline. 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 wi
by Maro 17y ago
Discipline.
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.
- hello_moto 17y agoMy 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.
- jrockway 17y agoIn 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.
- Silhouette 17y agoI think you're being rather unfair to Agile. 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.