Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

'Just Let Me Code!' 372

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."
This discussion has been archived. No new comments can be posted.

'Just Let Me Code!'

Comments Filter:
  • n00b (Score:0, Informative)

    by Anonymous Coward on Wednesday July 23, 2014 @04:21PM (#47517969)

    N00B, I've been dealing with that since the 90s. 75% or more of my time spent on project overhead and 25% of time spent coding.

  • Documentation (Score:5, Informative)

    by pooh666 ( 624584 ) on Wednesday July 23, 2014 @04:35PM (#47518099)
    I don't really follow what this guy is talking about in general. But one thing I have noticed is that documentation quality on new tools/APIs has steadily gone downhill. For example, I am really excited about node.js, but on the page proper, their docs just dump some bits of info on standard functions. That ends up making learning something new, really fast, more difficult than it used to be because you have to go to 3rd party sources, they may be full of crap, way out of date or both. It is one thing to have to put in your time to get comfortable with something new, but it is another to have to act like you are hacking a black box to learn it.
  • by Anonymous Coward on Wednesday July 23, 2014 @04:35PM (#47518103)

    Actually, there are plenty of doctors who would just like to treat patients. Instead they have to deal with insurance companies, malpractice, paying off their loans, etc. Just the other day I was thinking that this probably explains why there is no shortage of doctors who will give you a "420 recommendation" but there's a shortage of physicians accepting Medicaid patients. The Medicaid program isn't even being properly funded here.

    So yeah, the doctors would really like to treat patients; but there's no satisfaction in it because of the system and in some cases there's not even money. You can't blame some of them for becoming pot doctors.

    I guess maybe the equivalent of being a pot software developer is either to write black hat stuff, or work for the NSA or some other government agency that violates our rights. Kind of ironic, since the pot-heads would be on the other side if you took the government agency route.

    Anyway, your analogy is flawed. You're glossing over the real issues. Any profession can be bogged down with beurocracy and complexity that's perceived as interfering with certain human factors. You can't just gloss over the issue so easily. Some of these extra tasks have a purpose and can't be eliminated; some of them have no purpose other than to satisfy the irrational fears of those who hold the purse strings. Those can and should be eliminated.

  • by nimbius ( 983462 ) on Wednesday July 23, 2014 @04:43PM (#47518169) Homepage
    Anyone can write software, but to make it sustainable is a serious challenge. Ive worked at corporations where there was a coding standard that everyone "was expected to know" but it was never told to anyone on their first day (it turns out that was the oreilly perl best practices book.) Im currently working in a shop on a 15 year old application with a confetti development pattern that uses tomcat, jakarta, java, josso, struts, postgres and mysql, as well as a host of other malevolent and unsustainable technology with zero implementation docs and minimal code comments. I understand the love of coding, but as a greybeard i also understand the need for the managerial aspect of it as well so let me try to expound upon what it is we seek to do. im sorry if it comes across in an arrogant way.

    standards, practices, limiting scope and clearly defining goals and objectives prevent redundancy and wasted human time, which lets me keep devs longer because im not constantly sandpitting them in your 'just let me code' app. competent documentation and a service framework with a specific workflow ensure your application can and is debugged in a timely manner when it breaks, meaning I dont drive you out of the company with mandatory 24/7 pagerduty. ITIL and SCRUM are designed to ensure you arent a permanent part of the application, and that I can rely on other teams to help support it if or when you decide to leave for your next job at $corporation. Status updates and progress reviews really dont help you though, they help me. I need this information because at my meetings I have to run defense for you, my star coder. I need to know dates, times, and what it is that you're doing because I translate that into simple english for people in charge of my departments expenditures. "hes just coding" is never an answer i can give to my superiors, because ultimately as a management droid im responsible for you. if something breaks, thats actually my fault. and it makes the entire team look bad, despite it just being your code. If there is an unexplained cancellation and I dont convey it to you, that is also my fault and i expect you to hold me accountable. We're a team.

    I love creativity, i really do, because it means I've hired a good developer. Find a solution, write an application, code a system, but i fully expect you to design it and come up with a unique and functional way to make it the best. But unlike college, the things you do here will impact the company you're a part of for a long time. your code isnt just getting read-and-shred by the adjunct prof, its expected to perform a useful function for us and as such there are dramatically different standards and practices for how you need to code. im only sorry college doesnt teach this; it can be an uncomfortable awakening for many grads.
  • by i kan reed ( 749298 ) on Wednesday July 23, 2014 @04:57PM (#47518257) Homepage Journal

    I'm kinda surprised you chose C# as:

    A. Radically different from java
    B. "Fine for small projects"

    I code for work in C#, and for fun in either python or whatever is topical to the project.

    I used to code for work in python, and for fun in C#, and before that any mixture of java, C, assembly, and scripty-fu-fu suited my professors.

  • by msobkow ( 48369 ) on Wednesday July 23, 2014 @11:21PM (#47520403) Homepage Journal

    I believe he's bemoaning the complexity of frameworks and toolkits rather than the tools used to work with those frameworks and toolkits. Technically he's correct -- things are a lot more complex than they used to be for getting the most basic of tasks done.

    But you know what? Business isn't interested in basic tasks any more. They want it secure. They want it scalable. They want a web front end, and a desktop client, and apps for Android and iOS. The days of the old "read billing file, produce accounting records" code have not gone away; those projects were just done 30-40 years ago and don't need to be rewritten, just tweaked from time to time to allow for changes in regulations such as tax law or liability.

    Even the last company I worked for wasn't content with a mere rewrite and update of their core business with the new software -- they had a whole new plan of integrating another 5 or 10 vertical functionality features into the system (it was just an autodialer -- they wanted integrated CRM, push button customer calling, call answering, call forwarding, a full phone system with voice mail support and enhancements to the ever popular auto-answering system of branching menus and responses, and the ability to deploy the whole thing as a multi-client web service instead of deploying custom configured hardware to the client sites.)

    The frameworks and toolkits have correspondingly become more complex in order to support those needs. Look at the transaction processing systems of old -- you'd buy a number of seperate products including a message queueing system, a report formatting tool, a database engine, and a transaction processor, each of which had their own APIs and documentation. Each tool was relatively simple, but getting them all coordinated and working together was hard as hell. Now you take JEE, buy just about any message processor and database you like, and it all largely works with the same API regardless of which vendor's tools you chose. So while the JEE framework is incredibly complex compared to a transaction processor of old, what it does in total is also saving you insane gobs of time integrating and debugging disparate products. So technically JEE is far simpler than things used to be, despite the ramp-up learning curve.

    The same is true of every framework or toolkit I've used for over 10 years -- they tie together multiple vendors products consistently so that only small tweaks are needed to adapt to the vendor's products rather than whole-application re-writes if you decide to swap something out.

    Hell, take a look at what I did with Java, six different vendor databases, and JDBC alone for []. The differences between each of those database integration layers are not subtle, but nor are they particularly arcane. All of the products have virtually the same feature set; there are just differences in how you use JDBC and stored procedures for each database. Compared to "the old days", it was a cake walk to do that integration and customization over the past 3-4 years. And remember I worked on that code by myself -- it wasn't a whole team of programmers dealing with the complexity. If one guy can produce that using standardized toolkits in 3-4 years, how can you say things are more complex than they were when it used to take a team of 100-150 programmers 2 years to produce something similar for one database?

Never say you know a man until you have divided an inheritance with him.