|
> as a software developer [...], the world simply does not work that way. Well, the world is not a software developer, so hard to argue what would be if
it was. Or your grammar was off. > [being] a software developer who would gladly take all the time in the world to work on a problem for as long as I want, [...] "Taking all the time" to "work on a problem" is so boring. I would get fed
up with the problem after a quarter. "The problem" is actually a fractal of
things that need to be done before a perfect solution arises, and I've seen
many such fractals of work. Fortunately I'm a half-programmer, half-sysadmin, what results in me writing
tools for fellow sysadmins. Such tools are very, very rarely larger than
a dozen KLOC, so I tend to jump between problems and runtimes and languages
quite often compared to regular programmers. It's so refreshing to write Perl
after an Erlang application, to update shell script after writing a C library,
or to debug Python module after designing a network protocol, or to analyze
firewall behaviour after writing a Ruby plugin for data router daemon. Time constraints (realistic ones) give some framework to work with. They are
a good thing, if not abused. But the same stands for any other type of
constraints (memory, disk space, response time, specific runtimes that are
already present on target system, system's autonomousness, application's
transparency and monitoring, etc.). |