Comments on: Focusing my development effort http://blog.ngedit.com/2005/11/24/focusing-my-development-effort/ A blog on the development of the NGEDIT text editor Fri, 10 Sep 2010 01:27:47 +0000 http://wordpress.org/?v=2.3.2 By: J http://blog.ngedit.com/2005/11/24/focusing-my-development-effort/#comment-241 J Fri, 25 Nov 2005 18:01:22 +0000 http://blog.ngedit.com/2005/11/24/focusing-my-development-effort/#comment-241 Cool. Do you also hate many parts of programming as I do? That would be even cooler! (honest) You're suggestion is sensible, and I apply that often - what I often find, anyway, is that designing the interfaces (and especially with the more complex ones involving templates or whole subsystems) is the most work! Implementing single features is a breeze, and implementation becomes a problem when it requires reorganization of the code, and together with that, designing sensible interfaces... I'm glad anyway that someone else shares the pain - I can't stand the programmers who actually actually <em>enjoy</em> the process. (just half kiddin'...) Good luck with your endeavors! Cool. Do you also hate many parts of programming as I do? That would be even cooler! (honest)

You’re suggestion is sensible, and I apply that often - what I often find, anyway, is that designing the interfaces (and especially with the more complex ones involving templates or whole subsystems) is the most work!

Implementing single features is a breeze, and implementation becomes a problem when it requires reorganization of the code, and together with that, designing sensible interfaces…

I’m glad anyway that someone else shares the pain - I can’t stand the programmers who actually actually enjoy the process. (just half kiddin’…)

Good luck with your endeavors!

]]> By: ct http://blog.ngedit.com/2005/11/24/focusing-my-development-effort/#comment-240 ct Fri, 25 Nov 2005 01:28:32 +0000 http://blog.ngedit.com/2005/11/24/focusing-my-development-effort/#comment-240 we code very much a like. this strikes me often after reading your post. one thing that keeps me sane is, is thinking terms of a service architecture with multiple functionally aggregated apis. so when i divert to do some intermediary task, i get that missing api in place - even if just choosing the method names and interfaces, but only implement whats necessary to complete the actual issue in the issue tracker. so i end up with these 'intended' service apis to backfill later. that way i feel like im still doing the best thing to get beautiful code while minimising the diversion. we code very much a like. this strikes me often after reading your post. one thing that keeps me sane is, is thinking terms of a service architecture with multiple functionally aggregated apis. so when i divert to do some intermediary task, i get that missing api in place - even if just choosing the method names and interfaces, but only implement whats necessary to complete the actual issue in the issue tracker. so i end up with these ‘intended’ service apis to backfill later. that way i feel like im still doing the best thing to get beautiful code while minimising the diversion.

]]>