Podcast: Heinz Kabutz on Productive Coding

Discussions

News: Podcast: Heinz Kabutz on Productive Coding

  1. Podcast: Heinz Kabutz on Productive Coding (19 messages)

    Modern IDEs have revolutionized the way in which we are able to churn out code. In this podcast, taken from a session at TSSJS-Europe, Dr. Heinz Kabutz, publisher of "The Java Specialists" newsletter, demonstrates practical tips for coding Java "at the speed of light." According to Kabutz, most programmers are held back by bad habits and never fully utilize the power that is at their fingertips. To remedy this, Kabutz offers his tips on developing keyboard skills, writing useful comments, and refactoring quickly and correctly. Also covered are keywords such as "final" (not so final anymore in Java 5) and tools to help detect dead or duplicate code. View the slides for this presentation. What other tips can you offer for more productive coding?

    Threaded Messages (19)

  2. Speed of light[ Go to top ]

    Given that, even with good old vi, the average developer is able to code much faster than he/she can think, coding at the speed of light suddenly seems an odd idea. Also "leveraging" a IDE means specializing for a particular IDE. In the long run it is probably still better to learn one decent editor and learn it right (which noone does anymore). As for IDEs, the stuff that is really useful soon enough pops up as "fix this" icons or menu items, like "block comment" or "surround with try catch".
  3. Re: Speed of light[ Go to top ]

    the average developer is able to code much faster than he/she can think
    Then I must be way above average - :)
  4. Re: Speed of light[ Go to top ]

    Given that, even with good old vi, the average developer is able to code much faster than he/she can think, coding at the speed of light suddenly seems an odd idea.
    Why? It makes a lot of sense to me, and that's usually how I being my introduction to IDE's to people who don't use one: "I'm sure you're pretty fast with your current development environment, emacs, vi, TextMate or what-have-you. I guarantee that if you take the time to learn an IDE, you will never consider writing code otherwise, and you'll go faster than you ever thought possible". It's a good hook, and so far, I've had close to a 100% conversion rate, even with developers who use these IDE's very basically.
    Also "leveraging" a IDE means specializing for a particular IDE. In the long run it is probably still better to learn one decent editor and learn it right (which noone does anymore).
    Not sure I follow this point either... What's wrong with specializing for a particular IDE? Developers who don't use an IDE are already specialized with one particular tool, such as emacs, anyway, so why not do the same thing but with a modern and more productive tool this time?
    As for IDEs, the stuff that is really useful soon enough pops up as "fix this" icons or menu items, like "block comment" or "surround with try catch".
    That I completely agree with. One of the revolutions in UI brought forth by the current IDE's is that they make your job easier in a very discreet and obvious way. You might not know that "Ctrl-1" means "Quick Fix", but when you see the bulb appear in the margin, you click on it and you see several suggestions, with the first one usually being the right one, you immediately "get it". -- Cedric
  5. Re: Speed of light[ Go to top ]

    I'm sure you're pretty fast with your current development environment, emacs, vi, TextMate or what-have-you. I guarantee that if you take the time to learn an IDE, you will never consider writing code otherwise, and you'll go faster than you ever thought possible".

    It's a good hook, and so far, I've had close to a 100% conversion rate, even with developers who use these IDE's very basically.
    Sorry Cedric, my point was not so much that IDEs are bad, but that they are not at the core of developments productivity problems. I myself do use IDEs quite a lot, and I am somewhat faster than with traditional tools. Anyway, the embedded debugger, embedded checkstyle etc. definitely makes it worth using them. And they provide the major productivity boost, not so much the fact that I can spit out more code - Sideline: Thinking and turning out LESS code can be a huge advantage building systems that require maintenance at some point. But there are downsides: IDEs nowadays are considered something like MS Word - you just use them, they explain themselves etc. Which is why a lot of people don't care to learn there IDE (or even its embedded editor) up to a decent point. A downside for me, especially in the Java World, is that with most IDEs you will have to maintain two different build systems, one for the IDE and one for your actual scheduled builds. Also IDEs centric language evolution sometimes has the most curios effects (consider full blown JSP 2.1, which I am pretty sure is impossible to handle without an IDE anymore).
  6. Re: Speed of light[ Go to top ]

    A downside for me, especially in the Java World, is that with most IDEs you will have to maintain two different build systems, one for the IDE and one for your actual scheduled builds.
    Not if your IDE is using XML for the meta files. Then you just transform them into a neat little build file suitable for the scheduled build.
  7. utilize the power that is at their fingertips
    Developers' power doesn't come from their fingertips but from their brains. BTW: coding (defined as a transformation of design to code) is the least important part of development. http://www.enterpriseware.eu
  8. utilize the power that is at their fingertips

    Developers' power doesn't come from their fingertips but from their brains.

    BTW: coding (defined as a transformation of design to code) is the least important part of development.

    http://www.enterpriseware.eu
    Well, even if we the take the pretty conservative view that a design must be complete before coding can start, which in itself is pretty far detached from how most developers work, there is still the problem that requirements change, and hence specifications change, and hence design change, and hence code must change. When code must change, then a good IDE with good support for refactoring, can be a real productivity booster. But, of course, all that is really needed, for a "real" developer, is of course ed. I have seen young guys using this "vi" thingy, but I cant really see what the fuzz is all about. =)
  9. even if we the take the pretty conservative view that a design must be complete before coding can start
    The design (not design documentation) does always exist before coding can start (at least at the developer's head) and it takes much more time to come up with it than actual coding of it. http://www.enterpriseware.eu
  10. even if we the take the pretty conservative view that a design must be complete before coding can start

    The design (not design documentation) does always exist before coding can start (at least at the developer's head) and it takes much more time to come up with it than actual coding of it.

    http://www.enterpriseware.eu
    Right, thats why I used the word "complete", as in "a design must be complete before coding can start". Usually it isnt, and if it is, then it will change. When it changes, you will appreciate IDE support for refactoring.
  11. BTW: coding (defined as a transformation of design to code) is the least important part of development.
    Yeah, right, that's a fine statement, as long as you have competent developers that are also good at understanding and creating good abstractions. Once you've worked as a "high level" architect with bad developers, you'll realize no matter how good your "design" is, they will churn out something that looks nothing like it and falls apart in an instance. Seeing a hard split between "design" and "coding" is a very naive perception. Your nice bubbles, arrows and diagrams may be great, and they don't crash, but they don't do much either. It's the code that ultimately has to deliver on the promises, nothing else.
  12. Once you've worked as a "high level" architect with bad developers, you'll realize no matter how good your "design" is, they will churn out something that looks nothing like it and falls apart in an instance.
    In that case the problem is not design -> code transformation but high-level-design -> low-level-design transformation.
    Seeing a hard split between "design" and "coding" is a very naive perception.
    Not exactly. Keeping a design very close to code is one of the key ideas presented in "Domain-driven modelling" book and it's OK. But it is very different from thinking that design and coding is the same. Very often IT teams try solve difficult maintenance problems spedning all effort on "coding standards" thinking that good code formating etc. will automaticaly fix bad design or architecture (I'm not kidding it really happens). Design is something very different from coding. http://www.enterpriseware.eu
  13. In that case the problem is not design -> code transformation but high-level-design -> low-level-design transformation.
    What's the point of "low level design" if you've got incompetent monkeys doing the coding that barely glance at the design and implement it according to their own deficient ideas at the end? The developer who actually writes the code is the weakest and most important link in the development chain. A bad developer can botch up the most brilliant design ever conceived into crap code. A good developer can spot a bad design and come up with a good solution himself. "Design" and "architecture" as wholly separate tasks and responsibilities are only a result of people wanting to create more self-important titles for themselves.
  14. A bad developer can botch up the most brilliant design ever conceived into crap code.
    But with a new IDEs generation he can do this "at the speed of light". I'm not sure if that's a positive thing though.
  15. A bad developer can botch up the most brilliant design ever conceived into crap code.

    But with a new IDEs generation he can do this "at the speed of light".
    I'm not sure if that's a positive thing though.
    Well, the good thing is that will know it sooner.
  16. A bad developer can botch up the most brilliant design ever conceived into crap code.

    But with a new IDEs generation he can do this "at the speed of light".
    I'm not sure if that's a positive thing though.
    You'd rather this happened slowly? Whether the final outcome is good or bad, I fail to see why it's such a bad thing that IDE's allow you to code faster, and for that same reason, I also claim that IDE's don't make you code "worse". Put a good developer behind an IDE, you'll obtain a great developer. Put a bad developer behind an IDE, you'll get Stack classes that extend Vector :-) -- Cedric TestNG
  17. >A bad developer can botch up the most brilliant design ever conceived into crap code
    I don't think that this is actually true. Even if the developer is bad, the design - brilliant as it is - should be derived for the developer thus he must be able to implement it - or the design is simply bad. What you see much more often is that developers don't really care about the design - because no one explained it properly, or because it does not work and must not be changed, or, much more frequently, they figure out that no one will bloody check what they have coded before they will have moved to a different position. An architect visits the building, a software architect should visit the code far more frequently!
  18. What you see much more often is that developers don't really care about the design - because no one explained it properly, or because it does not work and must not be changed, or, much more frequently, they figure out that no one will bloody check what they have coded before they will have moved to a different position. An architect visits the building, a software architect should visit the code far more frequently!
    Holds some truth, but in some cases it is pure incompetence: I know cases where developers have not even known Java! You can question the rationale of formal "design", if you have to micro-manage developers and tell them how to code certain things for them to be anywhere close to hitting base. I would suggest in those cases that it is better to get rid of the incompetents and just let the people who know what they are doing get on with the job. What is often forgotten in these forums is that not every developer/designer/architect sits at home in the evenings reading up on new exciting developments and cutting code. Probably 70-80% of the industry is just 9-5 people who just want to get through the day and care nothing about improving their skills.. I happen to believe a lot of those 70-80% could be cut if the productive and motivated ones would be left to get the job done instead.
  19. The developer who actually writes the code is the weakest and most important link in the development chain.
    A bad developer can botch up the most brilliant design ever conceived into crap code.
    I experienced situations where that was indeed the case. However, I also met "architects" who would come up with idiotic designs, and project managers who couldn't manage. I've seen upper management people make key technology decisions on golf courses and had no clue of what they were doing. Of all these categories who could be considered weak links, the damage grows significantly in size when screw ups are made upper in the hierarchy. So, developers the weakest and most important link? I don't think so. It's easy to blame programmers, as their work is basically the only measurable thing in the process. Unfortunately, the biggest idiots are in management, and will continue to thrive there, as it's never their fault if things go bad.
  20. So, developers the weakest and most important link? I don't think so.
    Sorry, this might have been somewhat of an overstatement, my point however was that crap code will be detrimental to any other work on a project, just as well as a good developer with some initiative can easily make up for mistakes made in other areas of work, although perhaps not completely in all instances.