Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming

Getting Back To Coding 240

Posted by Soulskill from the trading-in-the-full-band-for-a-solo-acoustic-album dept.
New submitter rrconan writes I always feel like I'm getting old because of the constant need to learn a new tools to do the same job. At the end of projects, I get the impression that nothing changes — there are no real benefits to the new tools, and the only result is a lot of time wasted learning them instead of doing the work. We discussed this last week with Andrew Binstock's "Just Let Me Code" article, and now he's written a follow-up about reducing tool complexity and focusing on writing code. He says, "Tool vendors have several misperceptions that stand in the way. The first is a long-standing issue, which is 'featuritis': the tendency to create the perception of greater value in upgrades by adding rarely needed features. ... The second misperception is that many tool vendors view the user experience they offer as already pretty darn good. Compared with tools we had 10 years ago or more, UIs have indeed improved significantly. But they have not improved as fast as complexity has increased. And in that gap lies the problem.' Now I understand that what I thought of as "getting old" was really "getting smart."
This discussion has been archived. No new comments can be posted.

Getting Back To Coding More

Getting Back To Coding

Comments Filter:

  • Join a Free Software Project (Score:5, Insightful)

    by Anonymous Coward on Friday August 01, 2014 @01:53PM (#47583703)

    Write code.

    • Re:Join a Free Software Project (Score:5, Funny)

      by Austerity Empowers ( 669817 ) on Friday August 01, 2014 @01:59PM (#47583763)

      I tried but linux doesn't have a .vcproj or .sln. Someone told me they just use 'built in editors' but when I made a patch in wordpad, f5 didn't compile it.

  • Tool complexity leads to learning the tool (Score:5, Insightful)

    by jfdavis668 ( 1414919 ) on Friday August 01, 2014 @01:59PM (#47583761)
    I have an issue with my programmers when they know how to use the tool, but don't understand what they created. I overheard one group discussing a new system, and the one stated she didn't know where the code actually ran. No one in the group did. The Integrated Development Environment hid the details. No wonder people leave gaping security holes in systems if they don't understand how they work. I have really smart people who don't understand how the application server accesses the database. They just write code, and it works. They get used to figuring out how the tool works, not how the system works. If the tool is replaced, they are lost. If required, I'll go fix it in a text editor, because I understand what it's doing. I don't need an IDE to tell me. I know what information is flowing through the system, and how it does it. That way I can prevent inappropriate data from being exposed to outside users. IDE's are very useful to speed development, but you can't base your entire knowledge of programming on how to use a tool.

    • Sorry, that is nonsense.
      Every IDE places everything you edit ultimately into files, text files to be precise.
      The idea that something only runs in the IDE and otherwise no one knows how it works is just nonsense.

      • Have you ever used VisuSQL Server Integration Services? Obviously not.

        • Nope, I don't work with Microsoft Technologies.
          In 1997 a company I owned partly was so smart to use VisualSourceSafe as VCS (considering that it did not really work, I can not get why they did it).
          Instead of having files versioned in files they used like SVN the database approach. And yes they had back ups.
          When the VSS DB got corrupted, all work of two years of about five developers got lost. Well, mine was additionally in my private (back uped) RCS ...
          Due to licensing issues it took them months to get the backups back into a working VSS ...
          That was the last company I worked with MS 'tools' /languages for coding 'real' software.

          If your environment demands to use particular tools because vi and text files are not enough, then something is seriously wrong. And I doubt that absolvents from universities that only can use MS tools and can only work in MS ecospheres save so much money in the long run that it is worth it.

          • "Nope, I don't work with Microsoft Technologies."

            Then you admit that "Every IDE places everything you edit ultimately into files, text files to be precise" should have been "Every IDE I use".

            • Erm, if you want to point out that MS IDEs don't put stuff you work with into files, then say so. And if you are at it, explain where they put the stuff you enter (and if you know why, then point that out, too). Sorry, where else than in files should MS visual studio puts its sources?

              • Erm, if you want to point out that MS IDEs don't put stuff you work with into files, then say so. And if you are at it, explain where they put the stuff you enter (and if you know why, then point that out, too). Sorry, where else than in files should MS visual studio puts its sources?

                He/she doesn't have to say anything like that. Said person is giving you a counter-argument to your claim that every IDE does such and such. I can also give you another example IDE that is not MS and which does not necessarily put things in text files: Oracle's JDeveloper.

                And even if an IDE puts things in text files, that does not necessarily makes them readable or tractable.

                And here is the thing that you are missing when you first replied to jfdavis668. Your reply made references to IDEs whereas jfdav

                • He/she doesn't have to say anything like that. Said person is giving you a counter-argument to your claim that every IDE does such and such. I can also give you another example IDE that is not MS and
                  He did not give a counter example. He made a claim.
                  necessarily put things in text files: Oracle's JDeveloper I used JDeveloper ... and all I worked on was in text files ... care to point out, what is not?

                  Not all tools are IDEs. The OP is referring to tools that generate heaps of stuff (auto-gen code, property f

                  • Tools are used to tackle a certain technology. The xml files, property files etc. etc. are not there because of the tool. They are there because the technology requires them. So if your co workers or employees can mot master the technology without tools obscuring them, then that is certainly not the tools fault, regardless what tool is involved.

                    Well, duh! No fucking shit captain obvious. Neither I nor the OP you originally replied to said otherwise. Strawman #1 for you.

                    The next tool you want to abolish is a C compiler, because no one using it knows anymore how to code in assembler?

                    Who said anything about abolishing. The OP didn't say anything about abolishing tools (go back to what he/she said). He/she complained about people not knowing what the tools do, and that he had to clean the mess they leave because of it. And I echoed the sentiment.

                    I challenge you to quote me WHERE I SAID ANYTHING ABOUT ABOLISHING A TOOL. Go find that sentence of mine and quote

              • > Erm, if you want to point out that MS IDEs don't put stuff you work with into files, then say so.

                Um, I already did. That was the point of my reply. You effectively cannot edit the SSIS output except in the IDE. Theoretically, could you? Yes. But you could also theoretically manually edit binary files, too. The point is that the SSIS "text files" might as well be binary and it's really only reasonable to find a recognizeable section (like a SQL query) in the garbage and edit that. Editing beyind that so

          • We're currently using Visual Studio and Subversion. I'm not claiming that Visual Studio is better than vim/g++/gdb/make/gprof/etc., but it works well enough. My main complaint is how slowly C++11 features get into Visual C++.

            • Yeah, Visual C++ was always slow.
              I don't remember all the details, but I guess to have half working STL support too them roughly ten years.

      • Re: (Score:2)

        by maugle ( 1369813 )
        You missed the point. He knows where things are running and how to fix them if they break, but the other group knows nothing but "use the IDE" and they haven't bothered to learn what the IDE is actually doing behind the scenes.

        • He's doing them a disservice by fixing their problems. In the old days you bought a computer and there was no software for it, so you got a magazine with a program and you copied it in. You had no clue how the jumble of characters made it work, but it did ... until it didn't. If you dive in to fix the problem or to make it do something new on your own, you end up learning something about the system, about why things are the way they are.

          GP needs to stop playing daddy and let the newbs grow by fixing the problems themselves.

          • Oh, they learn all right. I only fix what is necessary to correct a production problem. It then goes back to the programmer to figure out why it was wrong coming out of the IDE. If 2 servers are not communicating properly, I know where the code executes which does that communication. Once band-aided to work, the programmer goes back to make the permanent fix. This often means wandering through configuration panels and wizards to determine what was set to generate the problem code. Once we figure out how to

          • He's doing them a disservice by fixing their problems.

            You do not know that because you do not know who the *other* people are, what their capabilities are and what work ethics they possess. If people don't care to know how the stuff they do for a living works, it is hard to help.

            Furthermore, the OP is not there to do a service to his peers, but to the company, his employer, the entity that writes him a check. I have been in the same situation, having to fix crap from peers who don't seem to know or care to know.

            The following speaks in general terms withou

        • Your wording is in the wrong order. It is not that they have not bothered to learn what us happening 'behind' the IDE. They simply don't know how a computer, a network or distributed software works.
          Either take them as programmers and let them use the IDE, or educate them about what they obviously did not learn in the university or simply don't hire them, but for god sake: stop complaining! If you hire people who don't understand how the code they produce is deployed to the production environment, then either make sure they don't need to know or ad I said above: stop complaining, change your recruiting habits!

      • You would be shocked. I envy your isolation if you have never had to work with or near people like this. Whole SOAP integrations are done from within Visual Studio. You push the "publish" button and now it runs "somewhere" (hint: Probably on an MSSQL Server somewhere, which is just god-awful).

        It is a longstanding joke in my office "We are the only ones in the world who know how to write software." Because every integration we do, is with companies who have 0 people who understand SOAP, SSL, Rest, or w

        • And why do you let that happen?
          So you write some code, 'publish' a part of it as WSDL and deploy it with a click of a button, then someone else uses said WSDL and writes code against it ...
          The WSDL is likely not even under version control as it is considered a build artifact?
          Well, honestly: system architectures are based on defining interfaces/WSDLs first, not but publishing them as a byproduct of some back office development ...
          Sure, tools make this easy ... but it is not the fault of the tools or the faul

          • Re:Tool complexity leads to learning the tool (Score:4, Interesting)

            by netsavior ( 627338 ) on Friday August 01, 2014 @02:52PM (#47584171)
            the reality of the real world is that you don't get to pick what your customers and your vendors do, you just have to code around their bullshit.

            • How can you expect old angel to understand your point, when he can't even distinguish who is who in your posts?

              He's just another angry aikido practitioner. The world is full of them. Oh, wait...

              • Aikidoka are usually not angry, at least I don't know any who is :)

                What was the point you are arguing about?

                Oh, tools are bad, yes ... it is never the user of a tool, is it?

                • That was my point, indeed. Such an angry person should probably be embarrassed to admit they do aikido in the same forum where they're YELLING AT OTHER USERS.

                  • I'm not yelling at other users, why should I?
                    They don't listen anyway.
                    Sorry, did again not get your point, must be an english / german language barrier thing.
                    I assume you had a point to make?

            • Well, there are other options:
              o pick a different customer
              o pick different vendors
              o educate your customer

              That "real world" thing would not exist if you would stop supporting it.

      • Re: (Score:2)

        by gweihir ( 88907 )

        The idea that the IDE becomes _necessary_ to access the code is spot on. We do code security reviews as part of our work, and, for example, most Java projects cannot be reviewed anymore without the Eclipse set-up that was used to produce them. That is pure insanity!

        • Sorry, that is nonsense.

          All java sources in an Eclipse project are simply in one or more trees of directories.

          If you can not cope with them without Eclipse then check them out of your VCS and use what ever editor you want.
          And bottom line I really wonder when you do intensive code reviews: why dob't you utilize tools like gerrit or fisheye for it .... eeeek, another tool!

          Oh, you do generate code with Eclipse or tools used by it? Perhaps you should then drop your academic attitude of 'not putting generated co

          • Re: (Score:2)

            by gweihir ( 88907 )

            You have obviously never done this. Pathetic. And no, we are not reviewing "our" software, quite obviously. If you knew the first thing about professional code review, you would know that coders and reviewers must never be the same or closely connected.

            You whole statement was possibly meant to drip irony, but it only drips confusion.

            • ROFL.
              So, you claim to know the difference between an 'inspection' and a 'walk through' but actually don't know it?

              And since when may the reviewers not have access to the VCS of the developers, regardless what kind of review style you chose?

              Sorry ... perhaps you should not only read the books your favorite professor suggests but also some others?

              There is no such thing as 'the right way doing code reviews' ... there are dozens of approaches, I mentioned two general categories above.

        • Re:Tool complexity leads to learning the tool (Score:4, Insightful)

          by RabidReindeer ( 2625839 ) on Friday August 01, 2014 @03:41PM (#47584611)

          The idea that the IDE becomes _necessary_ to access the code is spot on. We do code security reviews as part of our work, and, for example, most Java projects cannot be reviewed anymore without the Eclipse set-up that was used to produce them. That is pure insanity!

          If I was in charge, I'd march around the whole office and generously apply boot to fundaments.

          I got burned REALLY, REALLY bad in my Visual Studio days because it was difficult-to-impossible to get a makefile out of it, depending on which release you were working with, and once the IDE had been replaced with a newer version of the IDE, some projects couldn't make 1-line emergency fixes without either massive project rework or re-installing the old version of the IDE.

          Moving to Java wasn't much better, because although the IDE in question wasn't Eclipse, projects couldn't be built without the IDE plus the same directory setup as the original developer.

          Because of the expense and lost time at critical moments, I have a very strict policy that and project under my control must be buildable using a well-supported non-gui build system that can be set up and used in under 10 minutes with no external user system dependencies or other tweaking. In other words, Ant, Maven, or an equivalent product.

          • Sorry, but your claim that you can not build a Java project that originated in Eclipse, without having the same layout is not only nonsense it is bullshit.

            First of all I assume you mean directory layout _above_ package level?

            Then please explain me why a command line like: javac -sourcepath YOURSOURCE:FOLDERS:HERE -classpath JAR:FILES:AND:CLASSDIRECTORIES:HERE does not work on your system!

            • Re: (Score:3)

              by gweihir ( 88907 )

              I have to say I find Java apologist like you not only pathetic but repulsive. This "language" represents everything that is wrong with "modern" software creation. It is so badly designed, you cannot handle the sources without tools. It is so full of syntactic clutter, it is barely readable. It is so badly non-orthogonal, code re-use is a myth. Even badly written C or Perl is better. It is so slow and resource-hungry, that when you deliver some good-quality C-code that does the same, some people only believe

              • Well, if I was not on an iPad I simply would copy paste your rant and exchange every NOT for a yes and every "C can", with a "C can't" etc. p.p.

                If you really believe the **** you just wrote there, you don't qualify for discussions about software development etc.

                I only agree that Java is bloated, because the need of writing 'public' in front of every class and method and 'private' in from of every attribute is indeed a waste of time, and it is ugly to read.

                The rest of your post, especially the claims about h

      • Sorry, that is nonsense. Every IDE places everything you edit ultimately into files, text files to be precise. The idea that something only runs in the IDE and otherwise no one knows how it works is just nonsense.

        you're 100% wooshing it. the point is that the air-tards at his company know how to use the IDE but don't know what it does, and that's bad. everybody agrees with you that the IDE edits files and saves them.

      • Re: (Score:2)

        by Livius ( 318358 )

        The idea that something only runs in the IDE and otherwise no one knows how it works is just nonsense.

        However, the idea that 'something only runs in the IDE and otherwise some people don't know how it works' is depressingly common.

    • I agree. I like tools but I prefer them to fully expose what they are doing and why. I don't want my tools to hide the complexity, just reduce the tedious redundancy of implementing that complexity.

      • I think there's a few a few insightful quotes by Dijkstra and Wirth on the topic of tools. They were largely aligned with what you're suggesting. That's why Wirth went in the Oberon direction eventually.

    • A good rule of thumb is that you must understand your program at least one layer of abstraction past the user layer to be truly competent with it.

      That's frameworks, libraries, languages, whatever.

      This knowledge is often the difference between the experts and the experienced novices, and I think we all innately know this once we've experienced it. Java provides a nice example, because they build that requirement into their certification program and learn about obscured concepts like memory utilization and o

    • I have an issue with my programmers when they know how to use the tool, but don't understand what they created. I overheard one group discussing a new system, and the one stated she didn't know where the code actually ran. No one in the group did. The Integrated Development Environment hid the details. No wonder people leave gaping security holes in systems if they don't understand how they work. I have really smart people who don't understand how the application server accesses the database. They just write code, and it works. They get used to figuring out how the tool works, not how the system works. If the tool is replaced, they are lost. If required, I'll go fix it in a text editor, because I understand what it's doing. I don't need an IDE to tell me. I know what information is flowing through the system, and how it does it. That way I can prevent inappropriate data from being exposed to outside users. IDE's are very useful to speed development, but you can't base your entire knowledge of programming on how to use a tool.

      they don't need to know where the files are or where they execute. they're "in the cloud".

    • Re: (Score:2)

      by ADRA ( 37398 )

      Division of labor my friend. Would you rather the alternative being that all developers need to understand deep knowledge of the environments they're running on potentially conflating the cost of writing for your platform by double? I didn't think so. Not every developer needs to know about every inch of code that exists in your corporate hierarchy and libraries, infrastructure, etc.. as long as SOME PEOPLE ARE, are easily accessible, and willing to field questions as needed.

  • Do you speak it? (Score:5, Funny)

    by necro81 ( 917438 ) on Friday August 01, 2014 @02:01PM (#47583785) Journal
    Sounds like we need some Programming, Motherfucker [programmin...fucker.com]!

    Do you speak it?
  • FTFA "The reason that so many tools have become unwieldy is that they chase after certain values that add complexity but not usefulness to SMB-sized projects"

    If the author of the article would just choose his tools more carefully he could have saved himself these weird rants about things that he brings on himself. It's like a bike rider lamenting how uncomfortable his racing bike seat is when he's riding it around the block.

  • The problem mirrors that of big word processors (Score:5, Insightful)

    by darylb ( 10898 ) on Friday August 01, 2014 @02:06PM (#47583821)

    ...Everyone says "I only need 10% of what this word processor will do." Everyone else will agree with that statement. The problem? The 10% I need is not the 10% YOU need.

    I find the article strangely short-sighted. Sure, we have to avoid overengineering solutions that are not going to be needed in the near future. But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.

    A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."

    Further, our tools are complex because our needs are complex, even at the SMB level. I've been a developer for 30 years now, writing everything from experimental personal-use stuff, to local utilities, to enterprise software that is used by some of the largest manufacturers on the planet. Even small users expect unanticipated cases to work. Big customers expect that, not only do unanticipated cases work, but that migrations to new versions will be tailored to THEIR needs and will happen without notable incident. As but one small example that means that internal testing of a new release not only has to work as a brand new install, but it must also work as an upgrade, and it must work as an upgrade against the specific data and specific customizations (real software is customizable), even when you don't know what those are. If you expect success in that environment, you're going to need a LOT of tools: source code management (to identify what changed when you introduce a regression), an automated testing framework, a way to test builds and build functionality, a framework for testing upgrades against real customer data (that they let you use for this purpose), and then tools and processes that let you track code reviews, approvals, and the like. That's a lot of tools, and a lot of staff to follow it all around.

    My organization has some excellent tools, and developers assigned solely to maintain them for the rest of the development staff. It means, though, that any new developer coming in is going to have to learn a lot more than a programming language.

    • Re: (Score:3)

      by lgw ( 121541 )

      But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.

      When at last you grok the Tao of Programming in fullness, you will no longer have this problem. Seriously, one good reason to have a senior engineer on the team is to help guide you in doing just what you need immediately without significant throw-away work, or not-used-today cruft.

      A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."

      A couple of years? Writing dead code and cruft on purpose? No, that's nuts in this day and age. Write code properly such that it's easily refactored, and don't do anything to block anticipated features, but if you can't see wa

  • ...on how to best create software. It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on. There is simply not enough money being invested into making better programming tools. The fact that free, open source software is so pervasive in for-profit companies is proof of that. Everyone would rather take what they can get, squeeze as much money

    • Re:ultimately the misperception is by businesses (Score:5, Informative)

      by gweihir ( 88907 ) on Friday August 01, 2014 @03:17PM (#47584393)

      Really, that is completely ass-backwards. We do not need better tools. We need better programmers. I recently finished a medium sized project in C, using text editor, command-line compiler, commandline-debugger and svn only, and I found absolutely nothing wanting in my tool-chain. That was dual-platform development on Linux and Solaris (with the Solaris compiler and debugger on Solaris, not the GNU tools), and still, even an unified IDE would have benefited me almost nothing.

      Now, it may be that I am stuck in the dark ages of programming, but I don't think so. My development speed and result quality is entirely appropriate and significantly better than average. However, I have observed that many "programmers" are indeed helpless without exactly the complex tool-chain they are used too and cannot even produce simple code without the only IDE they know. These people have no business producing software and, indeed, they do not understand the language they code in or the machine they code for. They "muddle through" somehow, having their hand held by the IDE. It seems these people are the norm, not the exception. It is really no surprise so much software is so bad.

    • Maybe (Score:4, Interesting)

      by Anonymous Brave Guy ( 457657 ) on Friday August 01, 2014 @03:40PM (#47584603)

      It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on.

      Perhaps, but any such exploration and the resulting tools have to beat the baseline of a decent text editor, a decent version control system, a decent scripting language, and starting to write code within a minute of deciding the project is ready to begin.

      For a long-running project with many developers and other contributors performing repetitive or error-prone tasks, maybe it will be worth investigating, selecting and adopting some external tools to automate some of that work, at some stage in the project when you know where the pain points are. But if your development team aren't newbies, they will be perfectly capable of building their code manually at first, they will surely already know their universal Big Three tools very well, and importantly, they will just code up any basic automation on the fly as the project grows and the needs become apparent.

      IME, that turns out to be a surprisingly tough standard to beat. I've seen many, many projects get bogged down in their own infrastructure because they felt they should use some type of tool and forced themselves to do it, not because they necessarily needed that tool or found it useful in practice. Of course good tools can be useful, and of course sometimes it is better to bring in help from outside the project rather than being too NIH about everything, but it's important to stay focussed on the goal and not to forget that tools are only means to an end.

  • I'm in systems engineering/administration, so the vast majority of my "coding" experience is focused on automation and scripting. Predictably, stuff like this is very procedural and different from application development. However, the biggest shift I've seen is not really in the complexity of tools, but the shift in focus to gluing together pre-defined parts. Sure, languages have always had standard libraries, but development (especially in the mobile OS or web framework environments) often leaves me trying

    • No the trend actually is the same in application development - away from clean sheets, and towards lashing together complex components that can made to sort of work together, supported by complex development tools.

      It sucks, but I'm intentionally throwing more of my time now into learning the latest languages and development environments. Are they better? Not really. But you will never, ever convince anybody that fuddy-duddy is actually cool. They'll just think you're irrelevant. Every career has some

      • Re: (Score:2)

        by gweihir ( 88907 )

        It has gotten so bad, that if you are competent, you can actually code everything, excluding only the most standard libraries from scratch in the time it takes to get the components under control. Of course, using components leads to bloat, unwanted functionality (i.e. security problems), slow speed and low maintainability. Yet more and more people seem to be incapable of doing anything else.

  • c/c++, vi/emacs, make, ddd (Score:5, Informative)

    by mrflash818 ( 226638 ) on Friday August 01, 2014 @02:13PM (#47583881) Homepage Journal

    c/c++, vi/emacs, make, ddd.

    Lots of good years of use, likely many more years of usefulness, too.

    • Re: (Score:2, Redundant)

      by jfdavis668 ( 1414919 )
      Mandatory xkcd response - http://xkcd.com/378/ [xkcd.com]

    • Re: (Score:2)

      by gweihir ( 88907 )

      ddd? Not needed in most cases, unless you have created a mess. Also pretty hard to use if you only have a text-terminal. Plain GDB is actually pretty good.

    • Re: (Score:2)

      by sl149q ( 1537343 )

      The above have been my IDE for several decades. Spread across two 22" screens, each of which has four 132x60 rxvts, and of course there are several dozen sets of those available to support multiple projects. With another couple of screens for running Chrome and testing on.

      Every time I try to use Visual Studio I feel claustrophobic because I can't look (easily) at four or five separate files in their own windows.

    • Re: (Score:2)

      by ADRA ( 37398 )

      Which is precisely why so few developers per capita program in the languages any more. If tooling isn't making one's life easier year after year, you're becoming a drag on the industry. I'm sure you'll be quite happy driving your fully manual car decades from now when dual clutch cars own the highways, but most people won't care about how archaic your ride is, or how superior your belief in it is either.

      If you want to freeze your development platform into somewhere in the mid-80's, that's your right, but th

      • It's interesting how so many people seem to just assume that newer tools are needed for more efficiency/productivity. Assuming the same code needs to be produced, the important part is the knowledge required to produce that code and have it be efficient and of high quality. The tools have absolutely nothing to do with that aspect of the job other than to provide a level of comfort to the developer. That's a highly personal thing and necessarily prohibits any usefulness of a "my tool is better than yours"

  • I'm bitching about SQL Server Management Studio (Score:5, Insightful)

    by SethJohnson ( 112166 ) on Friday August 01, 2014 @02:14PM (#47583897) Homepage Journal

    Compared with tools we had 10 years ago or more, UIs have indeed improved significantly.

    No criticism of the OP here, but this got me thinking about one of my mortal enemies. The UI within SQL Server Management Studio. For the last decade of upgrades, I've really wondered how that development team leaves the office everyday thinking they are doing a good day's work. There are so many blatantly apparent rough edges to the UI for SSMS, I can't believe they think it's as good as they can make it.

    In order to avoid tldr, I'll just give a single example. Look at the tabbing for each database connection window. The tabs are labelled "servername.database" but are limited to a small number of characters regardless of how many tabs are open. Here's an example where there are only two open tabs:

    http://img.informer.com/screen... [informer.com]

    The first reason the labelling is fundamentally broken is that the database name is chopped off in an unnecessary abbreviation. The tab could stretch out to display the whole thing! It's not scrunched in with a bunch of other tabs. There's plenty of room there.

    The second reason this is broken is that the database name is the thing you actually need to see more than the server name. In the majority of use case scenarios, the user is connected to multiple databases on the same server. When switching tabs, you need to be able to locate the one for the database you're looking for within your current connections. Sure, there's that pulldown menu on the left, but that's a much further mouse drag than the tabs are from your focal point.

    So, if you're ever looking for an example of a developer interface that doesn't get a proper update, look no further than SQL Server Management Studio. It's hardly changed in over a decade of releases.

    • Yeah, I have a client using SQL Server and it is a royal pain. Luckily, most of the time I can accomplish my task by using an ORM+REPL from a modern langauge, like Ruby. Then I can just open as many REPLs as I need, or create multiple connections in one.

    • Am I the only person that insists on calling it Microsoft SQL Server?

      If the next version of Windows was called "Operating System", would you just call it that?
    • Check out the red-gate tools [red-gate.com] and ssmstoolspack [ssmstoolspack.com]. SSMS tools pack has saved my ass so many times. It stores every query you run in a local database.

  • Here is how to get in to coding: (Score:5, Insightful)

    by netsavior ( 627338 ) on Friday August 01, 2014 @02:19PM (#47583931)
    This advice is what I give people who ask me "how can I learn to program computers like you?"

    Build something. Find a problem and solve it. It doesn't matter what the problem is or how you solve it.
    Write a tic tac toe engine, or a photo slideshow generator, or a fart joke generator, or whatever you want to do. But you just have to do it.

    • Re:Here is how to get in to coding: (Score:5, Insightful)

      by ledow ( 319597 ) on Friday August 01, 2014 @02:25PM (#47583965) Homepage

      Precisely.

      I work in independent (private) schools. We have a few "star" pupils who want to be coders. They generally don't become them, not because they're not skilled, or couldn't do it, but because they've never sat down and done it outside of lessons that they waltz through. Following a course by-rote isn't learning.

      I also get asked an awful lot (by the younger years) how I type so fast and how they can "learn" to type that fast. Type. For years. Bang, you've learned. This is no shortcut, there is little technique, no amount of learning the home keys will help you type fast. You just have to type, lots, all the time.

      Same for coding. You can learn some theory. But to learn to code, you have to code. And with kids it's really easy - pick a game, program it. They know every kind of game, they will rarely fully complete anything approaching a full game before they get bored, disillusioned or just plain hit the limit of their skill level. The way past that point is determination and learning what to do. And that comes by just demanding that you code and discipline yourself.

      The true "stars" are the ones that persevere through those problems, solve them and come out the other end with ANYTHING approaching a complete program that isn't entirely trivial. Next time they have a coding problem, they know they just have to work at it to get past it.

      • Re:Here is how to get in to coding: (Score:5, Interesting)

        by vix86 ( 592763 ) on Friday August 01, 2014 @03:21PM (#47584435)
        I also get asked an awful lot (by the younger years) how I type so fast and how they can "learn" to type that fast. Type. For years. Bang, you've learned. This is no shortcut, there is little technique, no amount of learning the home keys will help you type fast. You just have to type, lots, all the time.

        While this very true; it helps to also give them a place that requires speed to push them to type fast. I've always told people that asked "how do you type so fast?" that I learned to type really quickly by growing up in IRC chat rooms with lots of people and multiple conversations going on at once. You had to learn to type fast to keep up with what was going on.

        Same for coding. You can learn some theory. But to learn to code, you have to code. And with kids it's really easy - pick a game, program it.

        The only problem I've ever had with using "games" as a way to learn to code is that the final product may not match expectations. To put it another way. I love programming because it gives me a means to solve problems. Sometimes the problems are concrete as "I need a piece of software on my desktop to tell me when I'm getting a phone call on my phone." That problem is focused, the solution is focused too. If your phone rings and you get a notification on your computer, you know you solved the problem.

        Games rarely offer up focused problems and solutions, especially for beginning programmers. A lot of game ideas are nothing more than "I want to make an RPG where I fight zombies." The solution would deceptively be to have a few characters in a bland world and some monsters labeled zombies, but game dev is never that simple and the problem space "grows." It goes from "rpg zombie game" to "rpg zombie hunting game where I must build a cure, save cities, and all while I'm working within this cool battle system." Games could be a great route to code but the path between problem definition and solution is huge compared to more simple stuff.
    • Comment removed based on user account deletion

      • Re: (Score:2)

        by Gestahl ( 64158 )
        An important concept in software development is don't duplicate effort. After someone has taught themselves a programming language from a book or sat through a uni course, better to convince people to find an existing project on Github or whatever, fix open bugs or start working on a feature addition that the devs have put on their wish list.

        He said learning how to code, not how to develop software. Important distinction. Learning a programming language is like learning how to read. Learning programm

      • You completely botched the concept. Doing something to learn is not duplicating effort because if it was done before, it was a different person learning. Somebody else's effort can't be transferred in some sort of Vulcan Mind Meld. Each person does their own learning, and learning projects are not going to be useful end projects anyways.

        And no, most projects on github are NOT in need of "patches." There is a glut of people who want to be contributors. There is not a shortage. There is perhaps a shortage of

  • "Featuritis" in the whole computing ecosystem (Score:5, Insightful)

    by gestalt_n_pepper ( 991155 ) on Friday August 01, 2014 @02:35PM (#47584021)

    New languages. New frameworks. New IDEs. New magic procedures...

    Some of it is good, surely. Who programs without classes these days? But every time I see someone come up with a magic new net language, framework, etc., I sort of cringe. I mean, do we really need another one? Do we need all the ones we have (I'm lookin' at you, Ruby...).

    The elephant in the room here that Microsoft, et. al. seems happy to ignore is that it takes time to learn AND recode this stuff. Time is money. If you're a teen or a student, you have time to mess with the next Ruby, or Dart, or GO, or BrainFuck or...

    As a kid, you have no money invested, and plenty of time. There's no risk.

    Fast forward 25 years. You still code for a living. You have a house, a wife, kid(s), car(s). You and your spouse are paying for all of this. Suddenly, genius boy at Microsoft invents Powershell! and convinces a few PHBs to roll it out. Suddenly, all your clients want Powershell! Quite frankly, you haven't got the time or interest in learning Powershell!. You wanted .net features added to VBScript and/or Jscript. You wanted backwards compatibility with existing VBscript and Jscript code. You wanted something that added value, not something that subtracted value by forcing you to go back to the drawing board and recode perfectly functional tools to satisfy a corporate IT security requirement from the corporate PHB that says, "Use Powershell!" for which you may, or not be paid, depending on how well your contract was written.

    Disclaimer: I like Powershell, but it was the wrong decision.

    The problem, quite simply, is this: Change!=Improvement. Change!=Better. Sometimes you get lucky. At other times, not so much.

  • Assembler only - One Coder - No backdoors. (Score:3)

    by MindPrison ( 864299 ) on Friday August 01, 2014 @02:53PM (#47584179) Journal
    Yep, I live in the stone ages, but at least I know every corner of my systems.
    • ...and btw, those systems are OFFLINE ALWAYS! ;)
    • *envy*

      I'm stuck in frameworky Java land. I want to slit my own throat. How the fuck do you manage to find a job writing low level code? I thought that shit died out in the 80s!

      • How the fuck do you manage to find a job writing low level code? I thought that shit died out in the 80s!

        I didn't.

        And no, that shit is far from dead. You'll find lots of assembly in specialized proprietary hardware where it's easier to just implement your own code instead of using an entire suite of libraries and ready made IDE packages.

        What I like about coding assembly, is that it's relatively straight forward, ok...the math really isn't as we don't have the luxury of floating points in every variable, various math function - and we need to keep track of our code jumps as the MCUs have certain limitati

  • That's all you need. (OK, implicit with c is the c compiler, pre-processor, assembler, linker, disassembler and strace). The old timers knew what they were doing.

  • Are you kidding? Efficient design peaked somewhere in 2000. Today, they're too simplistic, too spartan, and waste too much real estate, and then try to cover it up by sticking search boxes all over everything. The gap is only apparent because methods to complex processes have since been dumbed down for the benefit of illiterate users at the expense of making it as quick as possible for users who do know what they're doing to get at what is needed. This has made them harder to use for all but the simples

    • Re: (Score:2)

      by bored ( 40072 )

      I'm going to ad that I think usability with regard to discoverable interfaces probably peaked somewhere around 2000 as well.

      Since they we have have had one trend after another to make interfaces look slicker at the expense of discoverablity.

      First we started hiding visual hints (underscores on windows menus to indicate matching keyboard shortcuts). On and on, and lately we have the "flatten" UI paradigm where its impossible to even tell what is an active control from its surroundings until you start clicking

  • Welcome to the Next Level. (Score:5, Interesting)

    by VortexCortex ( 1117377 ) <VortexCortex@[ ] ... m ['pro' in gap]> on Friday August 01, 2014 @04:15PM (#47584947)

    I reached that point in the 90's.

    Now I write all my code in a meta language that compiles down into COBOL, C, C++, C#, Erlang, FORTH, Fortran, Google's Go, Haskel, Java, Javascript, Perl, PHP, Python, Ruby, Rust, and more.

    It takes about two weeks for me to learn a new language and write the "runtime" for my meta compiler. Then I can deploy all of my existing solutions on the new platform faster than the other guys can get "Hello DB Connection" out the door.

    Fuck all the shitty languages and "new" platforms. Now that you've actually grown up and stopped being a fucking fanboy, go write your own meta compiler. I'll open source mine when I retire, it's what gives me the edge over all the noobs still wasting time reimplementing their wheels.

    • Re:Welcome to the Next Level. (Score:5, Insightful)

      by JesseMcDonald ( 536341 ) on Friday August 01, 2014 @05:05PM (#47585337) Homepage

      That sounds like a great idea. Since you're coding for the least common denominator, you obviously get none of the benefits of the target language, while still suffering from all of its issues, plus whatever additional issues are introduced by your under-spec'd and idiosyncratic "meta language" and "meta compiler".

      To top it off, no one else will ever be able to maintain or build on what you write, so you're stuck with that job forever, unable to move on to something better—or at least until TPTB wake up and realize that it's far more trouble than it's worth and throw it out in favor of something which is properly idiomatic and standardized and which doesn't make them wholly dependent on you and your "meta compiler".

      No thanks.

    • I can see a 'meta-compiler' for C, COBOL, C++, and Java being a workable and useful idea (and there are plenty of open-source 'meta-compilers' for these languages), but I can't imagine it possibly being an efficient way to compile in Haskell or Python or Erlang. How would you integrate all the vastly different language features together? Answer: you can't, you have to use ugly workarounds that are slow, brittle, and very, VERY hard to debug.

      Until I am convinced otherwise, it seems that just the time wasted

  • for( mostly=0; mostly < lengthOfVec; mostly++) (Score:3)

    by DavidHumus ( 725117 ) on Friday August 01, 2014 @06:03PM (#47585769)

    How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood?
    How bloated is code because of the vacuousness of most common languages that
    require
    several lines
    to do
    the simplest
    things?

  • Tools just get worse. (Score:4, Funny)

    by LostMyBeaver ( 1226054 ) on Saturday August 02, 2014 @12:50AM (#47587495)
    15 years I coded with Qt professionally and came to love and adore it's quality and simplicity. I even wrote and operating system which was a microkernel and everything else was based on Qt Core.

    I wanted to make a simple project the other day and Qt failed me. It seems that code goes in without unit tests these days and shipments are made without any quality control.

    I used Qt because I'm not the typical loser Linux developer who wants to spend 50% of their time just fixing their tools or reporting bugs to package maintainers.

Slashdot Top Deals

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

Close