Slashdot Mirror
'Just Let Me Code!'
An anonymous reader writes: Andrew Binstock has an article about the ever-increasing complexity required to write code. He says, "I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. ... The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. ... Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity."
As things become more powerful, you can't just wish away the complexity. Maybe you can hide it in one of these 'shibboleth' things mentioned in the summary. That sounds big enough to hide things. Or maybe we could just use describe things more clearly -- but that's crazy talk.
I finally got to code when I switched from being an employee to being a consultant. My bill rate is high enough that they would rather me work than to get bogged down in meetings. Not saying it will work for everyone, but it worked for me. I've done more REAL work in the past two or three years than I did in the previous 10.
I recall attending a Microsoft Visual C++ Developer's Conference about 15 years ago, when COM and interfaces were all the new rage. I recall one MS guy giving a speech about the complexity of developing with it, bragging, "If it came down to usability for developers or functionality, we chose functionality."
I knew then I was dealing not with real engineers but with clowns proud of a college project.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Well, it's different in the ways that make a difference for me...which weirdly enough are "different syntactic sugar" and "a different IDE". It's not as different as it could be, but it does have the advantage of keeping me sharp in the same concepts Java uses as well. I don't have to yell at Eclipse when I'm at home, and I get legit excited when I can play with Linq. (What has my life become...) And that's enough to prevent burnout. But, projectwise, instead of writing backend server components for internet things, I'm writing one big program that decompiles an old retro game and extracts its map and graphics data with a nice graphical client. It feels too big for python. I guess at this point, "small projects" means "things that are not fifty-dev enterprise software things". Small enough that one developer can actually do it all.
I can say that being one dev in control of an entire hobby project makes me a better unit tester (seriously, what company actually follows its own internal UT guidelines) and is great for architecture experience, if you are a midlevel SDE on the rise.
There's probably something positive intellectually about having two languages with slightly different data structures; when you try to solve a problem the same way and are forced to make minor changes, you might find optimizations that are useful in both languages.
My hobby language used to be Multi-User Forth. That got tedious.