Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Programming

'Just Let Me Code!' 372

Posted by Soulskill
from the not-until-you-finish-your-vegetables dept.
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:
  • by Anonymous Coward on Wednesday July 23, 2014 @03:18PM (#47517941)

    ...just do it on your own time, and don't expect people to pay for it.

    He who pays the piper calls the tune...

  • by Anonymous Coward on Wednesday July 23, 2014 @03:18PM (#47517943)

    In the good old days you could go around opening people heads and fix their stuff. Sure, sometimes it went wrong or they died soon, but it was thrilling and exciting!

    People with nostalgia, keep crying a river, but far away from the rest of the world.

  • by Karmashock (2415832) on Wednesday July 23, 2014 @03:18PM (#47517949)

    Yeah there are some complicated tools but you don't have to use them. Use the old tools and code in the old way... most of them still work no problem. And even with the new ones there's simple ways to do the same thing.

    How many people are throwing up snipits of python code... its everywhere. I really don't know what the fuck this guy is talking about.

  • by horm (2802801) on Wednesday July 23, 2014 @03:19PM (#47517955)
    Engineering any complex system requires a significant amount of planning and management overhead. When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.
  • Bicycles and Jets (Score:4, Insightful)

    by bill_mcgonigle (4333) * on Wednesday July 23, 2014 @03:23PM (#47517995) Homepage Journal

    If you want to bring three hundred people half way around the world, don't try to do it on your bicycle.

    If you enjoy bicycling far more than piloting a jumbo jet, then you should be in bicycling, not commercial aviation.

    What, you don't like jumbo jets and nobody wants to pay you to ride a bicycle? Maybe you should invent the hyperloop or manage a B&B instead.

  • by Anonymous Coward on Wednesday July 23, 2014 @03:27PM (#47518025)

    This is a old song and dance. It's easy to create software, but it is difficult to create and maintain good software.

    Apply Sturgeon's Law [wikipedia.org] and be done with it.

    I'm tired of whiny youngsters, and not-so-young wimps who think they can program because they took a few classes, or got hired by a tech company who was desperate to hire anybody with even the slightest talent.

    Like the whining by Phil Fish in Indie Game [indiegamethemovie.com] movie about it being hard to write video games. Duh.

    Get over yourself, it's called work. Many people including many programmers have being doing it for several decades now.

  • by Matheus (586080) on Wednesday July 23, 2014 @03:29PM (#47518047) Homepage

    Sounds more like a cranky dev who graduated looking forward to creating Interesting Things(tm) and found themselves in the wealth of jobs out there creating What People Will Pay You To Do(tm) and is trying to find something grander than his lack of interesting job opportunities to fault it on.

    As stated: If you want to create something fun with simple tools THEN FREAKING DO IT! There is nothing in this world holding you back unless all you are willing to work on is what someone is paying you to do.

  • by MindPrison (864299) on Wednesday July 23, 2014 @03:30PM (#47518065) Journal
    ...Yep, got a pretty solid collection of those components, yesterdays micro controllers, CPU, Ram, Rom, Transistors, Tubes, Electrolytic Caps, Resistors, Varistors, Nuvistors and whatnotstors...

    Yep, they're old...but they've made me a finalist in various international Robotics competitions, given me freedom to invent stuff from scratch without making everything overly complicated, kind of like LEGO building bricks...you can make anything you put your mind to, and I like a CLUTTER FREE mind.

    I do feel the pain of many of todays youngsters who have to go trough extreme learning curves just to get into "the game" from scratch, not easy. Everything is specialized and we literally have no jack-of-all-trades coders anymore, pity...that's what we need IMHO.
  • by Anonymous Coward on Wednesday July 23, 2014 @03:31PM (#47518079)

    Actuall, during a surgery every scalpel move does not need to be pre-approved by some clueless administrator. The surgeon knows his job and does it with great freedom. He/She 'just do' brain surgery

    Nobody would survive a brain surgery if a physician would have to go through the same hurdles as a professional programmer

  • by Anonymous Coward on Wednesday July 23, 2014 @03:33PM (#47518085)

    With new processors being absurdly faster than they were 10 years ago, writing programs has never been easier thanks to the plethora of scripting languages available today. It seems like a lot of the tools are easier than ever to use, or still in use (make). Text editors like SublimeText or gEdit can help alleviate some of the terminal based text editor fear in a more "Word" like environment.

    IDEs can do some crazy shit with little or no knowledge of what's going on in the inside, just sit back and "enjoy" the magic.

    I personally write a lot of small programs, and I've never thought "this has gotten harder." Granted, I'm explicitly making the choice to use a scripting language instead of something like C, Java, Haskell, Erlang, etc. but due to the advancements in hardward-- why not? Unless you're programming low-latency server applications or games it really doesn't matter.

    Maybe it's just a problem of you not finding, or having the right tool for the job?

    P.S. Try scaling up a 100 servers on the cloud using Chef, then try doing that with tools/platforms from 10 years ago... No don't. It'd be irritating as shitting on an ant hill.

  • The price you pay (Score:5, Insightful)

    by petes_PoV (912422) on Wednesday July 23, 2014 @03:38PM (#47518131)

    The simple programs of a few hundred lines of C++ long ago disappeared from my experience

    I think the reason is, that people who pay for software have been bitten by "simple" programs too often.

    With a simple program: one where you open a file, do some stuff and produce an output - that always supposes that everything works as it's expected to. It assumes the input file has the expected name, that it contains the expected data and that the format is what you expect. It also assumes that the data will fall nicely within the bounds of "sensible" values, and that the output can be written as the coder expects.

    However, real-world data is never as neat as we plan for (especially when there is a deadline). There can be missing values, changed formats, some data is floating point or fixed and DATES. Can the "simple" code deal with DD-MM-YY and DD-MM-YYYY or even some people who randomly swap that day / month / year field order, or use names for months - or slip leap years into the fields.

    Basically, with the "simple" libraries that most of us use, there is a fundamental lack of robustness. Our code works with data we expect, but coughs a brick with something unusual - or from a changed specification.

    And then there's the security angle. There's always a security angle

    These are the factors that have made "coding" a complex business. Simply because the simple coding models we use to knock out a couple of hundred lines of code with, have shown themselves up to be wrong, limited an unreliable.

  • by QilessQi (2044624) on Wednesday July 23, 2014 @03:38PM (#47518137)

    As a surgeon, I long for the good old days when I could just give my patients a rag to bite on, grab my hacksaw or a good pocket knife, and BOOM, DONE. Now I'm forced to use an "operating room" which has to be "sterilized" along with everything in it -- you wouldn't believe the time it takes! My boss won't even let me use my own hacksaw; instead there's this bewildering array of "scalpels" and "clamps" and things -- they're supposed to make my job easier, but I spend half my time trying to figure out which one's the right one for the job. Oh, and goodbye rag -- I have to have an anaesthesiologist now, and IV tubes for blood and fluids, and all these doohickeys to monitor heartbeat, blood pressure, O2 sat, etc. It's a nightmare!

    Just let me cut!

  • by Sowelu (713889) on Wednesday July 23, 2014 @03:43PM (#47518163)

    May I also suggest that you make your work and your hobby /different languages/, so you can more easily separate them. When I've worked and coded-for-fun in Java at the same time, I'm miserable. When I started taking up C# at home (can the language hate, it's fine for small projects) I had a lot more fun. Work in the web industry? Write native apps for a hobby! You CAN code for work and for fun, but only if the projects are different enough that you can get in an entirely different headspace while having fun.

  • by Anonymous Coward on Wednesday July 23, 2014 @03:44PM (#47518175)

    You got that right....

    I'm working on my third decade at this job and I can assure you that the time you spend "coding" is actually one of the smaller tasks you have to do as a programmer. There are all the things you must do to get ready to code, the coordination with the people you work with, design and documentation to go with it and all the things you do AFTER you code, the testing, verification and debugging of the problems uncovered. There is also the "Oh Crap! I didn't write this!" time you use up when trying to figure out other people's code (or perhaps what they did to your code..). Not to mention the "What the!!!! What was I thinking?" time waster. Then there is all the logistics like performance reviews, filling out time cards and taking ethics and sexual harassment training...

    There are two ways to avoid all this...

    1. Only program for fun, not profit. Volunteer for some project, but keep it small.

    2. Only work in small ma & pop shops where you are the only programmer they have and none of your programs exceed a few thousand lines. Don't expect to make any money.

    If you want to make a living at this job, sit down and do the job. Stop griping about the parts you don't like....

    Now you greenhorn Java hacks who think a punch card gets you a free coffee can get off my lawn.

  • by Karmashock (2415832) on Wednesday July 23, 2014 @03:46PM (#47518181)

    Even considering all that, have a standard template that triggers all that crap and then build your little creative projects in subroutines.

    Is it harder to code in windows then in DOS? you're a lot farther from the hardware in windows. There is a lot more going on. But you don't see most of it because its abstracted or hidden away and mostly it doesn't matter.
    Do the same thing with all your debugging shit. Write a template that loads and manages all that shit so you can hack it like you want to while retaining compliance.

    If anything this guy just came up with a good coding project.

    Here you might say that your little coding projects and hacks need to be linked properly to these various systems and that can be a pain in the ass. But again... why are you doing that manually? Write a program or a script that automatically creates the links.

    What's left... documentation? First off, fuck you if you don't want to document your code and then implement it. Seriously. Fuck yourself with a chainsaw... sideways. I can't tell you how many shitty coding projects I've had to go through line by line trying to figure out how the fucking thing works or even what its doing because the asshole that coded it didn't document anything. I mean... some fucking comment lines every so often would be great.

    So what is left?

    Seriously... if you're a coder then you see all of this as something to fix... and then if it actually bothers you or interests you... you then fix it.

    Once you've built your little wrapper you can then hack it like you did in the old days and the program/script will dynamically create all the linkages and load all the debuggers and whatever the hell else you need to make the fuzzy bunnies happy.

  • by aix tom (902140) on Wednesday July 23, 2014 @03:46PM (#47518183)

    I agree, and that is actually a pretty good example on how it could/should work in IT also.

    You have an architect or an engineer to make the general plans, then split that into chunks the individual construction workers can handle, and then let them do their job. On top of that you have some sort of infrastructure specialist, who might not know much about bridges, but has determined that there is a traffic bottleneck at point X that needs a bridge.

    I would be perfectly happy to be either the architect or the construction worker in a project, but (for projects larger than a sawhorse) those two people SHOULDN'T be the same person. I that sense I sometime would also like to scream "Just let me Code!" instead of dragging me into all sorts of management meetings where people just sit around going "Say, wouldn't a bridge be nice?" First decide THAT you want a bridge, then decide WHERE you want a bridge, only then come to me to be the architect and get someone else to code, or get an architect that then gets me to code.

    But in IT a lot of unnecessary overhead is caused because people call big meetings of construction workers before having even decided if they want a bridge or not.

  • by Qzukk (229616) on Wednesday July 23, 2014 @03:56PM (#47518245) Journal

    When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.

    You also don't have the president of the company come in and declare that this week we're switching to agile bridge building and fuck six, we're going to seven sigmas so we can be on the bleeding edge and shift our paradigms into high gear to synchronize our release schedule and get out ahead of the pack as we swing around the final stretch into the processification.

  • by Motherfucking Shit (636021) on Wednesday July 23, 2014 @04:09PM (#47518357) Journal

    Let's say you're a competent Java developer and you'd like to build an Android app. I wish you the best of luck!

    First you're going to need to pick an IDE. I've always used Eclipse and hey look, there's an Android SDK for Eclipse. Perfect! Download, extract, fire it up... Errors. This version of Android SDK requires Android API version foo, you have version (foo - 9), please use the SDK manager to upgrade. The hell, the IDE bundle doesn't even launch out of the box?

    Alright, so you're distributing your IDE with an outdated version of your API, I can forgive that. Run SDK Manager like it suggested, let it do its thing,. Update available for SDK tools and SDK platform tools, looks good, do it! ...And, errors. Package not found, blah blah, let's see what Google has to say about this one.

    OK, apparently hundreds of other developers are having the same problem and have, after much wrangling, figured out a solution on their own. I see, I have to go into SDK Manager Settings, create a new User-Defined Add-On Site pointing to https://dl-ssl.google.com/andr... [google.com] because the URL that ships with the IDE is missing the "s" in "https" and that server doesn't have the right packages available to download. That highly intuitive process would surely have been my first try anyway, but at least someone else found the fix.

    SDK Manager seems to find the packages now, great! Got past that hurdle so let's do the upgrade. Wait, now what! What do you mean you can't upgrade to SDK Tools rev. 23 while SDK Platform Tools 19.0.2 is installed? I checked the boxes to upgrade them both; if Platform Tools has to hit rev. 20 before SDK Tools can be upgraded, why is the installer going in the wrong order?

    If and when you finally get the actual goddamned IDE installed and working, have fun with the official developer tutorials to create your first "Hello World" app. See, the API has changed over the years^Wmonth^Wpast week and so the app architecture that the tutorial talks about isn't valid anymore. XML files that it says should be there, aren't, so there's no way to follow along in the tutorial by editing them.

    I gave up on Android and won't touch it again unless I'm being paid to.

  • by michaelmalak (91262) <michael@michaelmalak.com> on Wednesday July 23, 2014 @04:40PM (#47518565) Homepage

    Yes, it is true coders have little time to code. But the author misses the primary cause: the ratio of library/framework code to self-written code.

    In the old days (say, 25+ years ago), you would pick up a book -- a single book -- of the OS API calls, memorize, and start coding. Today, with github, it's as if everyone in the world were working on the same single project. Today, a developer needs to learn all these libraries that are coming out daily and how to work with them. In the old days, there was a lot of reinvention and co-invention of the wheel. Today, that is not allowed, because one has an obligation to "buy" (for free) instead of build because of a) of course, development time and b) more importantly, one gets updates/upgrades "for free" without having to invest (much) additional development time, and c) one's organization can advertise in the future for developers who already have experience with that particular library/framework.

    To address specifically the reasons identified by the author:

    • Deployment. This is big, perhaps even as big as the above. In the old days, deployment was copying a single executable file. Today, not only is deployment to various and numerous servers more complicated, but for the past 20 years we've had people dedicated to managing those servers, called sys admins, to handle all those non-coding tasks. Of course, coders end up doing some admin and admins end up doing some coding, so now for the past couple of years we have a new half-breed, the Dev Ops. The very existence of both sysadmin and dev ops are themselves acknowledgement that coding is a smaller percentage of the total work involved.
    • Tools. The author spends most of the piece harping on this, and it's just totally bogus. We've always had source code control, editors, compilers, and linkers, and they've always been a pain at times to work with. But in fact, it's better now because you can find or ask about work-arounds and solutions on StackOverflow instead of calling up tech support at a closed-source vendor.

    But this new development paradigm of the global github hive -- where we're all essentially working on and contributing to this one massive codebase that we all have to understand -- is what the author missed. The amount of custom code to actually code is small now, and the majority of time is spent figuring out how to get the various libraries and frameworks to work.

  • by zidium (2550286) on Wednesday July 23, 2014 @04:43PM (#47518591) Homepage

    Same here. I hire out people to go to my meetings for me. No joke. It works GREAT!

  • by krlynch (158571) on Wednesday July 23, 2014 @04:43PM (#47518593) Homepage

    Of course brain surgeons don't "just do" brain surgery .... in any surgery, there's a ton of pre-operative work, investigation, preparation, paperwork, practice, etc. No one just dives in and cuts open your head.... and just as no one administrator hovers over the scalpel's every move, no manager hovers over every keystroke, either.

  • by Rob Riggs (6418) on Wednesday July 23, 2014 @04:57PM (#47518699) Homepage Journal

    The surgeon knows his job and does it with great freedom. He/She 'just do' brain surgery

    Nobody would survive a brain surgery if a physician would have to go through the same hurdles as a professional programmer

    Very true. By the same token, by the time your average programmer was done with your brain surgery, you'd have toenails growing out of your asshole for some inexplicable reason. "Oh, we'll fix that in the next surgery." *That* is why we have "clueless" administrators pre-approving their shit.

    The brain surgeon has to be worried about malpractice lawsuits; the programmer does not. The brain surgeon requires board certification; the programmer does not. The brain surgeon requires twice the education and years of formal, on the job training before he is ever allowed to operate; your average programmer thinks he/she can write shit-hot code before they even graduate.

  • by NormalVisual (565491) on Wednesday July 23, 2014 @05:06PM (#47518753)
    You are why spec and finished product do not match.

    I think the main reason why spec and finished product don't match is because "spec" is a moving target that never solidifies. Agile processes just make it worse by not even attempting to nail down requirements beforehand - "it's more important to be able to show progress than actually know what we're supposed to end up with, and don't you dare document anything because it's going to change anyway" along with the idea that it's okay to spend thousands of dollars completely rewriting stuff as the requirements continue to change. It's impossible to properly engineer a product when you don't even know what the product is in advance.
  • by NormalVisual (565491) on Wednesday July 23, 2014 @05:59PM (#47519073)
    OK, maybe that last one''s a stretch. Nobody bothers to document "simple" programs, since we all know the code IS the documentation and any good programmer can work out what is going on (are they still teaching that garbage?)

    Not just teaching it, *practicing* it. My boss is a hardcore Agile fan, and his official stance is "out of date documentation is worse than no documentation, so don't spend any time documenting anything, and if you can't figure out why this 12-year-old code is doing something, find someone in the group that does". Nice, except none of the guys that actually wrote that cruft are still there, and reading code doesn't necessarily provide any insights as to the higher-level theory of operation when multiple modules work together. Then on top of that, he says "I don't want to see any research tasks in this sprint". So what, I'm supposed to know how this works by osmosis?
  • by Anonymous Brave Guy (457657) on Wednesday July 23, 2014 @06:11PM (#47519129)

    Programmers are just cogs in a machine nowadays.

    Code monkeys are, and that's the way that managers who hire code monkeys like it.

    There are plenty of programmers out there creating interesting and useful new software, and plenty of customers/clients willing to pay serious money for the value that software offers them without all the unnecessary bureaucratic overheads and middle management crap.

    If you are a good programmer and professional in your general conduct, you owe it to yourself not to be a code monkey for anyone, IMHO. You have to be really, really unlucky with the time and place when your current gig(s) run out not to have better options in 2014.

  • by Paul Fernhout (109597) on Wednesday July 23, 2014 @09:06PM (#47520095) Homepage

    From: http://vpri.org/fonc_wiki/inde... [vpri.org]
    ---
    We are faced with a need for significant action and the odds are stacked against us. Invention receives no attention, and innovation (even when incorrectly understood) receives lip service in the press but no current-day vehicle exists to to nurture it. This wiki is an open invitation for talented individuals to pool their energy and collaborate towards fundamentally changing computing.

    Over the years many groups have debated how to make progress in computing. There were likely as many opinions as there were people in the debates. Nevertheless personal accounts suggest that initiatives were sometimes reduced to a handful and then pursued with vigour. Consider what could be achieved by following the same pattern today, with the added benefit of doing it as a virtual, distributed team.

    Our goal could be to capture the significant ideas and initiatives that we have been exposed to, are aware of, or can discover, distil them into groups, reduce them to a handful of concepts worthy of vigorous exploration, and focus our efforts on these common ideas with the eventual aim of making substantial progress towards finding a common set of fundamentals of new computing.
    ---

    See also: http://vpri.org/fonc_wiki/inde... [vpri.org]

    A big focus of FONC was in reducing lots of complexity. Smalltalk shows what is possible... But in practice new languages and new standards often just add more complexity to the mix and what we often need are better tools for dealing with complexity. And community and trends mean a lot too, as does hireability and ubiquity and easy installability. So, again, in practice, I'm moving to JavaScript with conceptually simple backends (even in, yikes, PHP) -- inspired in part by Dan Ingall's own work with the Lively Kernel which shows what is possible as near-zero-effort-to-install JavaScript apps.

    My own thoughts on FONC from 2010:
    "fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
    https://www.mail-archive.com/f... [mail-archive.com]
    ---
    Biology made a lot of progress by inventing the microscope -- and that was done way before it invented genetic engineering, and even before it understood there were bacteria around. :-)

    What are our computing microscopes now? What are our computing telescopes? Are debuggers crude computing microscopes? Are class hierarchy browsers and package managers and IDEs and web browsers crude computing telescopes?

    Maybe we need to reinvent the computing microscope and computing telescope to help in trying to engineer better digital organisms via FONC? :-) Maybe it is more important to do it first? ...

    It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)

    ---

  • by anyaristow (1448609) on Thursday July 24, 2014 @02:54AM (#47521027)

    That's because in the 90's programming got more difficult, and programmers *liked* it. No more soccer moms entering the field because they heard it was a way to earn a decent wage.

    Complexity makes programmers feel they can do things most people can't. So, they seek complex solutions. If it's not complex, it must not be the intelligent way to do it, since a lesser person could do the simpler thing.

    They have it backwards, of course. The ability to reduce the complexity of a task is actually a higher skill.

If you're not careful, you're going to catch something.

Working...