Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming

'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:
  • 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 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 i kan reed ( 749298 ) on Wednesday July 23, 2014 @03:57PM (#47518257) Homepage Journal

        I'm kinda surprised you chose C# as:

        A. Radically different from java
        and
        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 gutnor ( 872759 )
          C# is radically different. Your IDE, your test env, your OS, your frameworks, language features, ... all those are different enough so that you will not feel at work when coding with it.
        • by Sowelu ( 713889 ) on Wednesday July 23, 2014 @04:32PM (#47518507)

          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.

      • When I heard the Learn’d Astronomer

        WHEN I heard the learn’d astronomer;
        When the proofs, the figures, were ranged in columns before me;
        When I was shown the charts and the diagrams, to add, divide, and measure them;
        When I, sitting, heard the astronomer, where he lectured with much applause in the lecture-room,
        How soon, unaccountable, I became tired and sick;
        Till rising and gliding out, I wander’d off by myself,
        In the mystical moist night-air, and from time to time,
        Look’d up in perfec

      • by Xest ( 935314 )

        Don't really agree, I often use the same languages at home as work and I prefer it that way because I'm more productive due to being intimately familiar with the technologies in question.

        Most the work I've done in the last year has been C#, and I've been using it at home also. I'm much better off working like this than using say C++ for game development in my spare time because I can simply get more done. As an indie I'm not writing the latest and greatest FPS so C# with things like Unity, MonoGame and so f

    • by SQLGuru ( 980662 ) on Wednesday July 23, 2014 @03:55PM (#47518235) Homepage Journal

      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.

      • 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 epyT-R ( 613989 )

      True, but that doesn't mean those paying aren't getting exactly what they asked for. Dumb corporate policies cost money.

  • 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.

    • Depending on the environment in which you work. Where I work, there are source code auditing tools you are required to run against your code to meet various customer-imposed requirements; there are code-review tools... There are hardware debuggers that are tied to irritating IDE's like Eclipse... There is a veritable cornucopia of mandated tools, none of which actually help me to write code, but exist to make some manager or customer happy.

      I think what the submitter wants is to be able to 'hack' like the o

      • Re: (Score:3, Insightful)

        by Karmashock ( 2415832 )

        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 retain

        • by tepples ( 727027 )

          Most tools have their own APIs and many have their own DSLs. You either must learn a new sub-language or you have to program them. In every direction, complexity is an insistent reality poised to take you away from the core development activity: coding.

          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.

          The problem here is that once "a program or a script" reaches some level of generality, configuring it becomes almost as hard as just creating the links yourself. Hence the reference to application programming interfaces (APIs) and domain-specific languages (DSLs) in the article.

      • All those tools are pretty simple if you spend half an hour to,learn how to use them.
        But pretending they work as you imagine they should, that does not work.
        Commands set aside,a DOS's cmd.com is not a bash.

    • 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.

      • Re: (Score:2, Funny)

        by Anonymous Coward

        Yeah, I got into "computers" because I was looking forward to a subversive career in hacking into corporate systems and selling their secrets to their competitors and to undermining the US. Now we just crack systems so we can sell email addresses to guys pushing dick pills. Reality really sucks.

        • Re: (Score:2, Funny)

          by Anonymous Coward

          Lol, I like this complaining format:

          Yeah, I got into [specialty] because I was looking forward to a [edgy adjective] career in [exciting application of specialty]. Now we just [boring application of specialty] so we can sell [boring application revenue stream]. Reality really sucks.

          Example:
          Yeah, I got into machining because I was looking forward to a fast paced career in aerospace manufacturing. Now we just mass produce injection molds so we can sell crappy plastic coffee makers on ebay. Reality really suck

      • 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.

        Then how does one "create something fun with simple tools" and still eat? Besides, even if you have an unrelated day job, how does one "create something fun with simple tools" if the tools have to interoperate with other tools that are made available only to established companies, as in the case of developing games and other applications that run on devices commonly connected to TVs?

      • Going back to the time I learned to program my TRS-80 to play the Afghanistan national anthem on the little relay switch and except for teachers, three or four people have ever looked at my code. Perhaps I take the 'person' in personal computing a bit too personally. But it only took a week of working for a soulless minion of orthodoxy to get me to quit. I'm good at it and I love it. I still know the joy of programming. Years later, the first time I wrote and executed code on a Linux machine, well let's jus
    • by TheGratefulNet ( 143330 ) on Wednesday July 23, 2014 @04:05PM (#47518321)

      I fully understand what he's saying and he's right.

      I started doing software work in the early 80's and it was easy, fast and fun.

      now, its about 'scrum' and 'agile' and all that stupid shit (sorry if that offends). we had a simple life with makefiles and cvs, but now the librarians are complex and not intuitive, the build systems are uber complex and the CI (cont. integr.) stuff is a big change (and a whole system in itself) compared to the nightly build idea. code reviews, enforced coding standards add more slowness to the dev cycle. bug reporting systems are also complex.

      in short, its no fun anymore for us old guys. I fully see what he's saying. he's not talking about tiny snippets but getting shipping code out the door - its more process than it really needs to be, and the quality is STILL NOT THERE, so I don't think we made any real progress. and add in java where even idiots are allowed to write code (no need to free, whoopee!) and you have people who get lazy and if they ever have to write in C, they are totally lost.

      lastly, there are too many fad languages and this wastes everyone's time and since you can't be good at so many things, it spreads you too thin if a project has 5+ languages in it.

      • so I don't think we made any real progress

        Not only that, but we did it slower and at greater expense. Sometimes I go weeks without writing a single line of code anymore. It's really sad. I don't want to be in this industry anymore...unfortunately I don't have much of a choice.

    • 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 msobkow ( 48369 ) on Wednesday July 23, 2014 @10: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 http://msscodefactory.sourceforge.net [sourceforge.net]. 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?

  • 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.
    • 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 Junta ( 36770 ) on Wednesday July 23, 2014 @06:23PM (#47519209)

        those two people SHOULDN'T be the same person.

        In my experience, that is the heart of what is wrong with a lot of software projects: it's considered taboo to do both architecting and developing.

        The theory is obvious enough, but in practice an architect that is not implementing overlooks some very significant issues. The implementer has his hands tied because 'the architect said so' and the implementer trudges on also blindly unaware of anything beyond his little island.

        The best teams I've been in have had everyone participate in architecting and development, with healthy amounts of communication.

        The thing about construction projects is that they are simply so massive you need a horde of construction workers. In software development, we often like to *think* we are making something equally massive when in practice if we do need that many people working on it to get to the goal then it 99% of the time means we are doing something wrong in the first place. If we put hubris aside and realized that the scale isn't so grand as to require a trillion little dependencies and components, we produce good code. This doesn't mean the opposite situation of a gigantic monolithic blob is good, but there is a reasonable middle ground.

    • Engineering any complex system requires a significant amount of planning and management overhead. ........

      Engineering vs. building is an interesting distinction.

      Most complex products mandate long term maintenance, long term liability and multiple people including management and oversight.

      Sadly companies seem to invoke a one size must fit all process.... we have all seen the camel designed by committee of platypuses jokes.

      Worse some products like Android are big thunk monolithic update piles when they look and masquerade as small elegant Unix like programming problems to developers of olden days.

      Then there are

    • Yes, if a project gets to be large, then you need careful process. There are a few flaws though:
      1. A large proportion of the time, you are doing something far less complex and/or dangerous than bridge building. There are people who insist that for something akin to 'hello world' test cases must be written, everyone must use a bloated IDE, all code must be in version control managed by some project hosting site with issue tracking, wiki, code review, and continuous integration. Sure, there can be value in

    • 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.

      • This last post sort of hits the nail on the head.

        Yes, complex projects need to be managed, or you end up with dogpiles like most of today's ERP stuff (and many others). But by managed I mean managed WELL.

        Managed WELL does not mean all sorts of overhead and red tape that exist just because a clueless project manager doesn't know any other way than one-size-fits-all full-blown project management according to some textbook. It means using tools wisely as the project's needs demand, neither more nor less.

      • by Anonymous Coward on Wednesday July 23, 2014 @05:23PM (#47518865)

        What about synergy? Where is the GOD-DAMNED synergy!? Oh shit, this project is totally going to fail.

    • Your analogy is unacceptable. You should have written it in Esperanto. Esperanto is the new standard for analogies from corporate. Also, you should have simultaneously posted it to your FaceBook account which you are required to have if you wish to perform analogy services on this network. Furthermore, you did not submit your prose to the grammar nazi trolls, or allocate time for analogy review in the scheduling program. Please rectify these discrepancies and I will get back to you during my appointed

    • I read the article/rant, and he's bitching about the complexity and time required to learn and use modern frameworks and tools, not so much about planning and management. The summary is a bit misleading.
    • by meburke ( 736645 )

      Not a bad analogy, but Engineering follows the rules of Physics and Chemistry, which were built on layers and layers of scientific thought and experiment. Hardly anyone writing code these days understands what's happening under the hood.

      Disclaimer: I've been programming since 1965. I'm proud of the fact that I can create logic gates that will do medium to complex mathematics.

      Programmers have become like lawyers: They are sometimes competent technicians but are not required to engage in original thought. We

      • We need thinkers who can define requirements precisely, designers who can describe processes to produce those results, and then turn the design (UML. Warnier-Orr, Flowchart, etc.) over to a generator

        We already do this, that generator is called a compiler. By the time you have specified a design to the same detail as an engineer specifies a bridge you have already written all the code. Engineers specify a design down to every individual bolt. Software specifications do not design down the individual line of code. This is the difference between engineering and programming: in engineering when a design is completed then the object still has to be built, in programming when the design is completed then

  • I find Vi/G**/Make is still pretty simple. And things like SDL, GTK, QT, etc. simplify things even more. Having watched Windows development evolve for a long time I can sort of see what the submitter is saying but on the other hand anyone who ever wrote a C program for Windows in the 90's using the original Petzold [charlespetzold.com] books should really appreciate the frameworks available for Windows programming these days.

    Again, I'm talking "Coding for fun, hobby, learning" here, just simple stuff. If it's a business app or

  • by Joe_Dragon ( 2206452 ) on Wednesday July 23, 2014 @03:23PM (#47517987)

    It seems that you did not put the new cover letters on them.

    • It seems that you did not put the new cover letters on them.

      Actually I did. I just used the economy ink setting so you have to squint really hard to see it.

  • 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.

  • Some sort of mega-all-in-one SCM, IDE, build tool, project management software nightmare?

    Honestly, I think developers on big teams have it easier. Part of my job is to do some of the less exciting operational stuff so that they can spend more time coding. (We unfortunately lump in the build process with coding, even though it's not that sexy.)
    • Some sort of mega-all-in-one SCM, IDE, build tool, project management software nightmare?

      That's my text editor, you insensitive clod!

  • 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.

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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

  • 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

    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" t

  • Tools make it easier for project managers and execs to try to collect data from developers for compliance initiatives, and the additional (and often unnecessary) burden that places on a development team in turn compromises development efforts, including those not directly related to coding.

  • Documentation (Score:5, Informative)

    by pooh666 ( 624584 ) on Wednesday July 23, 2014 @03: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 Tablizer ( 95088 ) on Wednesday July 23, 2014 @04:24PM (#47518453) Journal

      You don't gettit. See, if they documented node.js well, it would no longer have "nerd cred"; it would become Yet Another Boring Framework/Tool with 20 titles out like Learn Node.Js in 7 Days Unleashed Bible Face-First into the Deep End Without Water instead of an elite tool for elite nerds who can master the arcane and obtuse to write the distributed 3D TwitterFace.com and Fix ObamaCare.org in 3 days.

  • 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 Krishnoid ( 984597 ) on Wednesday July 23, 2014 @03:41PM (#47518153) Journal

    As things become more powerful, you can't just wish away the complexity [wikipedia.org]. 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.

  • by cptdondo ( 59460 ) on Wednesday July 23, 2014 @03:43PM (#47518165) Journal

    That's why I work with vi and arduino, or openwrt.... Much more fun, simple, and I can do almost anything I need done.

    But yes, it's a fixie, not a jumbo jet. It's what I like doing, and I happen to make a living at stuff like that. If you are hired to build a jumbo jet, then you need jumbo tools and jumbo overhead. If you don't like it, scale down, hang up a shingle, and get a client. You might be surprised.

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Wednesday July 23, 2014 @03:43PM (#47518169)
    Comment removed based on user account deletion
  • by Daniel Hoffmann ( 2902427 ) on Wednesday July 23, 2014 @03:48PM (#47518197)

    void *unemployment;
    struct hell *reality;

  • "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."

    You can't exactly get everywhere you need to go via bicycle these days. Blame globalization.

  • I have really come to love the creative exercise of scripting my job responsibilities on the operations side of things. I can keep it simple, or make it complex. I can adhere or not adhere to whatever style I wish. I make the cost-benefit analysis as to whether I'm going to write it or not. I can share it with my coworkers as soon as there is an obvious benefit, or keep it on the down-low if it is not yet ready for prime time.

    I own my scripted 'products' and I reap the full benefits of them.
  • Comment removed based on user account deletion
  • 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.

  • This guy sounds like a twentieth century doctor probably sounded as the medical field started to become highly specialized. There are few things in life in which we make progress and make things simpler at the same time. It's the reason that you can't see the ground anymore while looking into the engine compartment of your car and it's the reason that laws are more numerous and more complex than ever before. Sometimes it's nice to look back at the simpler times with nostalgia, but there's no going back,
  • The fundamental problem is that developers do everything. Heck, even in companies where there are entire teams dedicated to the task, developers still up doing them.

    Maybe it's just because organizations are short staffed, lack of training, lack of skilled specialization. I won't dwell on the causes. I'll just state the reality.

    In some theoretical world, source control is handled by a separate team, environment setup is handled by a separate team, testing is handled by a separate team. Each of whom are skill

  • by Applehu Akbar ( 2968043 ) on Wednesday July 23, 2014 @05:02PM (#47518729)

    This new language is as much fun to code in as Python without the pure-interpretive overhead. The latest Xcode includes a "playground" prototyping space that makes it easy to experiment with pure code, including library API calls, before cementing your work into the application framework of iOS or OS X. Right now it's a one-manufacturer language, and still beta, but something tells me it's going to spread.

  • part of my nostalgia for coding on the C64 is how you felt you could know everything about the box. There was a book, Mapping the C64 and C64C [amazon.com]. that told you about every single address on the computer. You felt you could get everything done with some pokes and peeks, or some machine language. (LDA anyone?).

    Now, you can do more, but you don't feel you can push to the envelope of the hardware. How many classes does java add every release cycle? How often does CPAN turn over?

    I think im not the only one wit

  • If you have a project that's too big to fit into 1 person's head and you want it to work right and be maintainable, you either have to have a team of people who practically read each other's minds or you have to have a solid design and maintenance process.

    Either that, or you have to accept that unless you get lucky or your code is hardly ever used, you will have problems down the line.

    Having a lightweight or non-existent process is fine for projects that can stay in one person's head and which won't need to

  • 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

    If I was supposed to derive joy from it, I'd be paying my employer to do my job rather than the other way around. I'm being paid because I do it for their benefit, not for mine.

  • by WaffleMonster ( 969671 ) on Wednesday July 23, 2014 @05:13PM (#47518807)

    Source control, IDEs, build systems and bug trackers... are all very ancient tools that tend to make people more productive so they can spend more time coding... leaving me puzzled and confused by TFA's point.

    He seems to be saying enabling infrastructure to manage a product lifecycle is more difficult or at least non-trivial vs. problem space itself... Suppose if your one of thousands of shops churning out proverbial flashlight and fart apps this could well be the case...otherwise it is hard to understand how it can be true. While supporting infrastructure can and does become very complex for large development efforts there are usually tooling peeps on staff who specialize in each subdomain.

    What makes matters worse you go on to hate DSL's, use NoSQL databases... which leaves me little choice but to assume you hate everything good and nice.

    Either that or you got screwed working for some grossly understaffed rinky dink company with reams of old code nobody understands who lied when they used the word "developer" in job description...LOL.. happens...a..lot.....

  • by Trillan ( 597339 ) on Wednesday July 23, 2014 @06:37PM (#47519287) Homepage Journal

    I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.

    Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.

    Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"

    Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:

    The long, laborious setup:
    git init

    Saving changes:
    git add --all .
    git commit -m "This is what I did."

    Undoing changes before saving them:
    git reset --hard
    git clean -fd

    Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.

    Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!

  • 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 Casandro ( 751346 ) on Wednesday July 23, 2014 @10:30PM (#47520431)

    It's an attempt to get the most "bang for the buck". Essentially you write lots of small programs which have limited and well defined functionality, then you hook them up any way you like. In fact taken to the extreme (as with Plan9) you can do anything with simple shell scripts.

    BTW there are simpler developing environments out there which have a decent feature set, without the complexity of a C(++) toolchain. Lazarus is just one example of it. Of course you then loose flexibility. Lazarus, for example, is mostly suitable for GUI applications. Writing a webserver with it is hard. Of course it does GUI decently well, allowing you to have one codebase compiling from everything from your bog standard Linxux (GTK) over MacOSX, Android to even exotic platforms like Win32.

  • by TsuruchiBrian ( 2731979 ) on Thursday July 24, 2014 @01:57AM (#47520933)

    I would also like to point out that back when it was every coder did everything himself from scratch (i.e. the good old days), the actual products sucked. There was a lot of fun work to be done reinventing the wheel millions of times over, but when 99.9% of the wheels had serious flaws, it was pretty hard for the user of these wheels to get any real work done.

    So it turns out that most programmers are terrible, and they think it's fun to reinvent the wheel, because wheels are the only thing (they think) they understand. They think learning new tools are "boring" or "stupid" but mainly because it's hard to do things in a way you aren't already used to and "hard" things are "stupid" to people that want to use the rationale that the only reason they might not understand something is if it's stupid. The smart programmers learn to use the tools because it actually makes more efficient use of the time spent programming.

    There was a time when programmers complained that compilers were stupid because there was no need to write in a high level language when you could just write in assembly code instead.

    The smart programmers weren't the ones that could read and write in assembly and didn't need high level languages. The smart ones were the ones who recognized that high level languages would make programming more efficient and created that tool.

  • 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.

A good supervisor can step on your toes without messing up your shine.

Working...