Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Getting Back To Coding

Soulskill posted about 2 months ago | from the trading-in-the-full-band-for-a-solo-acoustic-album dept.

Programming 240

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

cancel ×

240 comments

Sorry! There are no comments related to the filter you selected.

Join a Free Software Project (5, Insightful)

Anonymous Coward | about 2 months ago | (#47583703)

Write code.

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

Austerity Empowers (669817) | about 2 months ago | (#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.

Re:Join a Free Software Project (1)

Anonymous Coward | about 2 months ago | (#47583829)

So basically, your poking fun at the fact that VS users can be productive on a larger scale in a shorter amount of time?

Yeah... let me learn VIM and linux command line to make a program. That'll show those VS users a thing or two *Rolls eyes*

Re:Join a Free Software Project (2)

Austerity Empowers (669817) | about 2 months ago | (#47583903)

Visual Studio/Xcode:
I can call spirits from the vasty deep.

Real Programmers:
Why, so can I, or so can any man;
But will they come when you do call for them?

Re:Join a Free Software Project (1)

lgw (121541) | about 2 months ago | (#47584329)

Oh, believe me, with Visual Studio they'll come - when you least expect them!

Re:Join a Free Software Project (3, Funny)

Anonymous Brave Guy (457657) | about 2 months ago | (#47584455)

Visual Studio/Xcode casts Summon Spirits.
Spirit appears.
Spirit appears.
Spirit appears.
Spirit attacks Real Programmers.
Real Programmers attempt to save against arrogance... and fail.
Real Programmers have been frozen in time.

Re:Join a Free Software Project (0)

Anonymous Coward | about 2 months ago | (#47583991)

I can use vim and Linux command line when the task at change changes, but you can't use Visual Studio for more. But I guess you're lucky, because then the company has to hire more people for those tasks. Hmm... I may be on to something. I'm not contemplating having a lobotomy so that I can work in a big company without being abused for my skills...

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

jfdavis668 (1414919) | about 2 months ago | (#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.

Re:Tool complexity leads to learning the tool (2)

angel'o'sphere (80593) | about 2 months ago | (#47583807)

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.

Re:Tool complexity leads to learning the tool (1)

mattwarden (699984) | about 2 months ago | (#47583823)

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

Re:Tool complexity leads to learning the tool (3, Interesting)

angel'o'sphere (80593) | about 2 months ago | (#47584017)

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.

Re:Tool complexity leads to learning the tool (2)

Oligonicella (659917) | about 2 months ago | (#47584191)

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

Re:Tool complexity leads to learning the tool (1)

angel'o'sphere (80593) | about 2 months ago | (#47584331)

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?

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584453)

Shh, the Linux people want to believe their shit editors from the 80s makes them better programmers. Hey, I can edit files in notepad and stab an icepick in my balls too.

Re:Tool complexity leads to learning the tool (1)

turgid (580780) | about 2 months ago | (#47584783)

I can edit tens of thousands of lines of code in an instant with sed and grep without even "opening an editor." Through the miracle that is sh I can pipe stuff into my custom (very small and simple) C and sh tools to frob the code. Then I just type make to rebuilt it all and my unit tests tell me that it worked.

At the other side of the office, they're cursing and swearing and Microsoft(TM)(R) Visual(C) Studio Intergalactic Azure Edition For the Enterprise(R) because it's still importing the project...

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584335)

>...1997...That was the last company I worked with MS 'tools' /languages for coding 'real' software...

So you're basically ignorant on the topic but decided to chime in anyway? Thanks so much for your valuable input. The contributions of people like you make Slashdot the place that it is today.

Re:Tool complexity leads to learning the tool (1)

angel'o'sphere (80593) | about 2 months ago | (#47584589)

I'm ignorant about MS.
Not about the topic, none of the GPs or the original poster ever mentioned MS.
But if programming means for you to work with MS technologies (erm, can you name that technology?) then ... hm ... I pity you.

Re:Tool complexity leads to learning the tool (1)

zidium (2550286) | about 2 months ago | (#47584897)

Big big words for an Anonymous Coward!

Even though I totally 100% agree with the AC who said they can use notepad and shove an icepick in their eyes too lol! I deal with those sorts ALL THE TIME. Esp. the SublimeText fanatics who wouldn't recognize a debugging breakpoint if they saw one.

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584315)

Totally irrelevant. SSIS is purpose-built to be a visual tool. That's not coding (you can of course use Script Tasks but it is by no means necessary).

Additionally, the .dtsx output is just an XML file. You can read it if you want.

Re:Tool complexity leads to learning the tool (1)

maugle (1369813) | about 2 months ago | (#47583845)

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.

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

Boronx (228853) | about 2 months ago | (#47583905)

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.

Re:Tool complexity leads to learning the tool (1)

jfdavis668 (1414919) | about 2 months ago | (#47583961)

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 fix it, we then deploy over the patch to create a proper deployment package. Again, we are learning the tool, not the code.

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

angel'o'sphere (80593) | about 2 months ago | (#47583937)

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!

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584533)

Honestly, who gives a shit? If they can roll out productive code faster, more power to em. Who gives a shit about the nuances of SOAP when that can be abstracted? I sure don't. If something goes wrong with an abstraction, just fucking google it. It's not hard.

We get paid to produce working, well written software. If it takes someone 2x as long because they refuse to use productivity tools, they are 1/2 as productive and deserve 1/2 the pay. They can go on and on about how artisan their software is, but the people who cut the checks really don't give a shit.

This is the reality of professional software development.

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584573)

Oh, and one more thing, if you are using any language that is assembler or higher, guess what? You are using a fucking abstraction.

Re:Tool complexity leads to learning the tool (1)

netsavior (627338) | about 2 months ago | (#47583869)

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 whatever flavor of the month bullshit that they demand we provide.

It is not like we can't tell what is going on, when we get a 4 meg Microsoft WSDL.

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47583913)

What are you babbling on about?

If you have a 4Meg definition file you are doing something seriously wrong.

Re:Tool complexity leads to learning the tool (1)

netsavior (627338) | about 2 months ago | (#47583959)

well yeah, duh. That was the point of my post.

Re:Tool complexity leads to learning the tool (1)

angel'o'sphere (80593) | about 2 months ago | (#47583977)

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 fault of the users of those tools if YOUR ORGANIZATION, your software architects, your software department allows this!

Re:Tool complexity leads to learning the tool (3, Interesting)

netsavior (627338) | about 2 months ago | (#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.

Re:Tool complexity leads to learning the tool (1)

Aighearach (97333) | about 2 months ago | (#47584401)

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

Re:Tool complexity leads to learning the tool (1)

angel'o'sphere (80593) | about 2 months ago | (#47584477)

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?

Re:Tool complexity leads to learning the tool (1)

Aighearach (97333) | about 2 months ago | (#47584731)

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.

Re:Tool complexity leads to learning the tool (1)

angel'o'sphere (80593) | about 2 months ago | (#47584491)

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:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584577)

Hell, most of the time you don't get to pick what you do. 'Allow'!?!?! What a laugh. Try telling your boss that you won't 'allow' poor tools...

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47584391)

Visual Studio is partly a RAD tool.

It doesn't have to be a black box but it can be if that's what you need.

Re:Tool complexity leads to learning the tool (0)

Anonymous Coward | about 2 months ago | (#47583885)

And there are many people like you who have difficulty reading text that's not annotated, explained or highlighted by something else.

Re:Tool complexity leads to learning the tool (2)

lgw (121541) | about 2 months ago | (#47584429)

And there are many people like you who have difficulty reading text that's not annotated, explained or highlighted by something else.

I used to program using butterflies [xkcd.com] , but of late that doesn't seem manly enough. Now I'm programming by arranging cocoons such that weeks hence when the butterflies fly away, the desired atmospheric disturbance will result in the code on my HDD. Took years to get to where I could intuit the changing weather well enough, but now I feel like a real programmer again - let's see em make an Emacs macro for that.

Re:Tool complexity leads to learning the tool (1)

gweihir (88907) | about 2 months ago | (#47584293)

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!

Re:Tool complexity leads to learning the tool (2)

angel'o'sphere (80593) | about 2 months ago | (#47584433)

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 code' into version control?

Do you have a build system that can build your project from the command line? No? Why not? How do you even know that the security audits of the code you audit actually cover the code soon to be in production?

So now you blame Eclipse ... it is just a tool! And a fool with a tool is still a fool!

If blame an IDE for deficiencies in your software or software development process ... then there is something wrong with your approach, seriously!

Re:Tool complexity leads to learning the tool (1)

gweihir (88907) | about 2 months ago | (#47584871)

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.

Re:Tool complexity leads to learning the tool (3, Insightful)

RabidReindeer (2625839) | about 2 months ago | (#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.

Re:Tool complexity leads to learning the tool (2)

angel'o'sphere (80593) | about 2 months ago | (#47584801)

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:Tool complexity leads to learning the tool (2)

Noah Haders (3621429) | about 2 months ago | (#47584661)

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: Tool complexity leads to learning the tool (1)

GrantRobertson (973370) | about 2 months ago | (#47583873)

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.

Know at least one level deep of abstraction (1)

quietwalker (969769) | about 2 months ago | (#47584397)

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 object creation, but examples exist elsewhere. That 'Aha!' moment when you read Effective C++, or when you grok EF, or understand why Backbone.js does the things it does in the way it does them. I've even seen it on graphic designers who were forced to write raw HTML and CSS, rather than Dreamweaver or Muse.

This isn't even a program-from-bare-metal argument, it's just simply a matter of understanding the underpinnings in order to write decent code, instead of just adequate code.

Re:Tool complexity leads to learning the tool (1)

Noah Haders (3621429) | about 2 months ago | (#47584639)

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:Tool complexity leads to learning the tool (1)

ADRA (37398) | about 2 months ago | (#47584681)

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.

IDEs are for wimps (0, Informative)

Anonymous Coward | about 2 months ago | (#47583783)

My development chain starts in the terminal (I program mainly for Linux; your Windows experience may be impossible to adapt to match). I have vim as my editor (and have nothing against people who use emacs). Once in a blue moon I try a GUI editor (like gedit, geany) or an IDE (like Eclipse or Netbeans), and I always find myself going back to vim, because everything else slows me down. My documentation is on the Net. If I need to know something about an API I google it. I don't miss autocomplete very much, as if I know what I want then vim's Control+N suits me very well. If I don't know what I want, then autocomplete will not really solve it for me anyway. I write my own makefiles, and call the auxiliary tools (is a compiler "auxiliary" to editing code?) knowing very well what I want them to do. For version control I also use the command line, because GUI tools never seem to help, and always seem to hinder.

I find myself very productive given that I don't use "productivity enhanced" tools.

What I would very much want is a fucking GUI editor for Android apps, because editing XML files from scratch is getting on my nerves. I don't know what makes it so much more annoying than editing straight up HTML though. Maybe I just didn't familiarize myself the Android GUI XML well enough to use it, but given how easy it is to do things in Xcode for iOS, I think Google need to put some effort into it. I think Xcode is pretty much the only IDE that didn't get in the way when I needed to use it, but I can't use it for more than iOS apps, or on Linux so...

Re:IDEs are for wimps (0)

OzPeter (195038) | about 2 months ago | (#47583969)

Once in a blue moon I try a GUI editor (like gedit, geany) or an IDE (like Eclipse or Netbeans), and I always find myself going back to vim, because everything else slows me down

What I would very much want is a fucking GUI editor for Android apps, because editing XML files from scratch is getting on my nerves.

So you dislike GUI's but secretly desire one?

I'd posit that your anti-IDE/GUI experience is based around tools that don't meet your needs, and your XML editing desires show that you are looking for tools that meet your needs.

I'd also posit that having the right tools would make you much more productive than bare bones editors (compared to a fully fledged IDE)

Re:IDEs are for wimps (1)

Aighearach (97333) | about 2 months ago | (#47584443)

Sorry Petey, but the coward was very clear. He doesn't like IDEs for GUI editors normally, but the only place (android) where he thinks it would be useful, the options suck.

It wasn't actually a hard one to understand.

And he has a point, because XML is designed to be human readable in the loosest sense, but it is not designed to be actually written by humans. And CLI tools are very awkward on android, because most android devices don't have a physical keyboard. If you're knowledgeable enough to be commenting on this story, you should know all that already.

Do you speak it? (5, Funny)

necro81 (917438) | about 2 months ago | (#47583785)

Sounds like we need some Programming, Motherfucker [programmin...fucker.com] !

Do you speak it?

standard "use the right tool" applies (1, Offtopic)

trybywrench (584843) | about 2 months ago | (#47583789)

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.

Part of the problem already given in summary (0)

Anonymous Coward | about 2 months ago | (#47583793)

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.

To be fair, that's because many new techniques and tools are focused on maintenance and not the initial writing of code. It's fairly obvious that you wouldn't see much benefit of things focused on the post-project during the construction of the project.

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

darylb (10898) | about 2 months ago | (#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:The problem mirrors that of big word processors (0)

Anonymous Coward | about 2 months ago | (#47584013)

Here is the thing. I *could* go back to using just vi and fixing scripts and code. Would I? Oh hell no. Those tools when I use them make things zillions of times easier. Auto lookup of function prototypes and a short explanation on each one and the params? Yes please. Or go back to the old way and grep thru the files and hope you find the prototype and hopefully someone put a comment on it. Or maybe the docs are up to date. Tools that show interdependency of functions and easy ways to refactor names? Yes please. Or go back and use sed/awk and grep and hope you get it right. Someone blarfs a checkin why did they do it? Was it an honest mistake? Or were they doing something you do not understand?

These tools help. Most of the time it is a matter of just knowing they exist and how to work them. Could I go back. Sure. Would I? Why?????

The only thing that grinds my gears is the number of different text editors out there. Do we really need another one? Is your use case that special that you need a whole new editor for it? I doubt it.

The second thing that grinds my gears is the speed that these frameworks run at. I kept an ancient copy of visual studio 6 for a long time. Just because it started very quickly. vs 2012 takes ages to startup. I accidentally clicked 2008 yesterday then started 2010 right after it. 2008 was up in 2-3 seconds. 2010 took minutes 2012 is even worse. There is no reason for these frameworks to take that long to startup. They in the end are basically glorified text editors. Dont even get me started about eclipse or netbeans.

Re:The problem mirrors that of big word processors (2)

Aighearach (97333) | about 2 months ago | (#47584517)

People using vim or emacs would have automated tools that build documentation listing the function prototypes, and would spend the 2 seconds to open up said document when working on a project, and will just keep it open. Generally people using these tools make use of virtual desktops and have all of these tools open and available all the time.

Just because you don't know about a workflow doesn't automatically mean it is in the dark ages ;) it might just mean you're in the dark ages and don't even know what the workflow options in popular use are.

Why do options you don't use "grind [your] gears" just by existing? Don't you feel like a total sociopath admitting that? Why would a new software project need your approval just to exist, or meet your expectation of a highly specialized use case? Almost everybody using an "editor" is using vim or emacs, and none of the "editors" force users of a file created in it to use the same editor.

Also, you said the "only" thing that "grinds [your] gears" is one thing, and then you listed a second thing, as a "second thing." If even your English isn't self-consistent, no wonder you need an editor, and no wonder everything would be totally borked if you attempted sed! lolol

Re:The problem mirrors that of big word processors (2)

lgw (121541) | about 2 months ago | (#47584501)

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 ways to do just the immediate work and still keep it cheap to add someday-maybe features later, what have you been doing these 30 years?

Re:The problem mirrors that of big word processors (1)

turgid (580780) | about 2 months ago | (#47584719)

Truly, you are at one with the Tao.

ultimately the misperception is by businesses (2)

a4r6 (978521) | about 2 months ago | (#47583831)

...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 as they can out of it in the near term, and wait around to benefit from everyone elses investments back into the technology.

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

gweihir (88907) | about 2 months ago | (#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 (3, Interesting)

Anonymous Brave Guy (457657) | about 2 months ago | (#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.

Less coding, more assembling pieces (1)

ErichTheRed (39327) | about 2 months ago | (#47583865)

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 to figure out how much I would have to code from scratch and how much work has been done for me simply by including Massive Functional Library X. Don't get me wrong, it's a good thing to not have to do everything yourself, but I sometimes wonder how much control one gives up when they just write an app by putting someone else's code together.

One example from my side of the fence is Windows PowerShell. It's amazing, but it really requires a complete shift in thinking if you're used to writing VBScript. JavaScript or batch language automation. With the other languages, you have to write lots of code to parse command output or iterate through a WMI structure. Some of the stuff is so complex that sysadmins who don't really know the under-the-hood workings just cargo cult the whole thing and make a mess. PowerShell became useful to me when I realized I no longer had to write chunks of code solely dedicated to reading the contents of formatted CSV files. Lots of the complexity of that rolls up into a line or two of script. Again, it's not a bad thing, but if you're used to DIY, it makes you wonder how the "magic" is being done. When you move up the stack (iOS, Android, etc.) that abstraction is even more stark...as in, just call this library which handles the entire database-access layer that used to be huge amounts of coding.

Re:Less coding, more assembling pieces (2)

timeOday (582209) | about 2 months ago | (#47584217)

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 drawbacks, and spending your life chasing fads, coupled with others' disdain for everything you did or learned over a decade ago, is a drawback of this one. (Heck, why didn't you start a successful startup or at least move into management by now, anyways?)

Re:Less coding, more assembling pieces (1)

gweihir (88907) | about 2 months ago | (#47584437)

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.

Microsoft and Borland (0)

Anonymous Coward | about 2 months ago | (#47583867)

The trend was started by Microsoft and Borland in the 80s. Apple bucked the trend by staying w/ C, then C with objects, and now Swift. Java, while a really nice thing to drink, was just an easy version of C++, or an easier version. Visual Basic was popular for years, because it was easy/easier. Microsoft's tools like Visual Studio, are difficult for someone like me that comes from a much easier and productive database environment. COBOL and FORTRAN were early attempt at the language making programming much easier. I was in the business for years, and drawing a screen and creating a database was a snap, compared to what the rest of the world was doing. Then, it gave me a niche to work in.

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

mrflash818 (226638) | about 2 months ago | (#47583881)

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

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

Re:c/c++, vi/emacs, make, ddd (1, Redundant)

jfdavis668 (1414919) | about 2 months ago | (#47584131)

Mandatory xkcd response - http://xkcd.com/378/ [xkcd.com]

Re:c/c++, vi/emacs, make, ddd (1)

maligor (100107) | about 2 months ago | (#47584287)

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

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

No-one in their right mind would use vi (I can navigate around it, but it's a PITA). I have to assume you mean vim. which is a very nice editor. And I've never used DDD and I never saw the purpose to it, gdb text mode seems easier to use, and it includes some fancy text mode ui features for register and code tracking, that some people might not be familiar with. I don't have anything against GUI debuggers, but DDD is pretty much an ancient throwback. Something like the QT Creator integrated debugger is actually reasonable.

Re:c/c++, vi/emacs, make, ddd (1)

gweihir (88907) | about 2 months ago | (#47584463)

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:c/c++, vi/emacs, make, ddd (1)

sl149q (1537343) | about 2 months ago | (#47584547)

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:c/c++, vi/emacs, make, ddd (0)

Anonymous Coward | about 2 months ago | (#47584809)

One thing I really like about emacs is the ability to have multiple windows open on the same file. I do not know what other editors offer that as I have been using emacs since the DEC-10 days. I have been forced to use different editors over the years and some different IDEs too. All I remember about them is that when I am unable to do this, I really feel handicapped.

I do not mind people using their favorite IDE. Don't even mind if I am required to "use" one at work. I will just do my work within emacs and then import the files into the IDE.

What does bother me are the people who are clueless about what happens when they hit the "build" key. I had one individual who insisted that the compiler was "remembering" the ".h" files from previous compile compile cycles, that somehow constants set for one compile were remembered for a different compile on totally different files. He had no idea what was happening "under the hood".

So it does not matter what IDE you are working with, as long as you are ale to - at least in theory - able to get by with an editor, compiler and linker to create your program. Not that you will do it, but that in theory you would be able to if required.

Re:c/c++, vi/emacs, make, ddd (1)

ADRA (37398) | about 2 months ago | (#47584879)

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 the industry has moved on, and effeciency of development has long surpased most CLI based tooling for anything non-trivial. I wish you all the luck in the world though.

I'm bitching about SQL Server Management Studio (4, Insightful)

SethJohnson (112166) | about 2 months ago | (#47583897)

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.

Re:I'm bitching about SQL Server Management Studio (0)

Anonymous Coward | about 2 months ago | (#47584365)

the full connection information is at the bottom of the window in the status bar, and changes to match the current window's connection info:

server\instance (version) | user (spid) | Current db name | last query time | last query @@rowcount

Or (SSMS 2012), drag the window so it's not docked on the SSMS container, and the window's tab will expand out...

What I with the SSMS Object Explorer would do is let you also filter the list of Databases like you can for Tables, etc., as well as allow for regular expressions. It's querying SMO, coded in .Net, right?

Not quite as stupid as Excel using multiple documents...

Re:I'm bitching about SQL Server Management Studio (1)

Aighearach (97333) | about 2 months ago | (#47584561)

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.

Re:I'm bitching about SQL Server Management Studio (1)

NoImNotNineVolt (832851) | about 2 months ago | (#47584811)

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?

Here is how to get in to coding: (4, Insightful)

netsavior (627338) | about 2 months ago | (#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: (4, Insightful)

ledow (319597) | about 2 months ago | (#47583965)

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: (4, Interesting)

vix86 (592763) | about 2 months ago | (#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.

Re:Here is how to get in to coding: (1)

Pro923 (1447307) | about 2 months ago | (#47584277)

Agreed. And if you have a talent for programming, you can get vast amounts of stuff done this way. The problem is, when you get into the corporate environment they tell you HOW to solve the problem, how they want the tic tac toe engine written and what variety of project management tools that you need to satisfy each and every time you make a change to your fart joke generator.

Re:Here is how to get in to coding: (1)

CRCulver (715279) | about 2 months ago | (#47584305)

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.

I rather disagree. There are already applications out there to do those things. 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.

Doing that teaches you how to craft patches and work with a team. Coding isn't generally a solitary thing any more, a person has to learn how to meet other people's expectations, writing code that the community around them can work with. Employers also seem to be more impressed with a portfolio of involvement in larger projects (which are by nature team efforts) than single-person itch-scratching.

Re:Here is how to get in to coding: (2)

Gestahl (64158) | about 2 months ago | (#47584585)

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 programming itself is like learning basic English composition skills (i.e. write a 5 paragraph essay). It's easy to study, easy to evaluate, and easy to review, and you can focus on the details of syntax, semantics, grammar, and style. The logical analysis, presentation, and cites are important (the start of engineering and reuse, etc), but not the focus. Learning software development/engineering is like learning how to publish a properly annotated, logically argued and presented, and cross-referenced scholarly paper suitable for a journal. It (should be) a foregone conclusion that your syntax, etc. is proper. Now the focus is on consistency, coherency, structure, reuse of existing material, and aesthetics.

Re:Here is how to get in to coding: (2)

Aighearach (97333) | about 2 months ago | (#47584647)

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 quality contributions, but having people still in the initial learning stages submit pull requests is not useful to anybody, it is just pollution. You don't even do what you recommend, it is obvious from your language; nobody accepts patches, or reviews them, on github projects. You submit pull requests.

Learn first. Repeat what others have done in the past. Implement a bunch of known wheels in the various known ways. Keep doing. Keep doing. This is how you learn. Then when you finally have a pull request to send, it is for a feature that was actually needed, and not "me too" vanity code.

Yeah, and ....? (-1)

Anonymous Coward | about 2 months ago | (#47583967)

There hasn't been anything new in CS since the 80s.

No really.

Nothiing.

It's all been marketing bullshit - yeah, just because they are F/OSS doesn't mean there isn't marketing. As many of you pointed out, money isn't everything.

Now, this right tool for the right job nonsense. It's all syntax. If I gave you an assignment to parse a data stream in COBOL and you couldn't do it? FAIL!

Cant do it in PASCAL? Fail!

BUT you need Perl? Fail!

Now, write an os for a Motorla 123456 processor?

Well then, you found the exception to the rule. Hardware,and only hardware, requires the RTFTJ.

A computer scientist would realize the differense.

And non of you - nor the H1-bs - know this.

You ALL suck.

-Yours truly,

A hiring manager who hires Americans.

Yeah, and ....? (1)

varwwwawesomecodersi (3772439) | about 2 months ago | (#47584209)

I don't really understand what you're trying to say here. I don't know COBOL. Are you saying that if you gave me an assignment to parse a data stream in COBOL, and I couldn't do it in COBOL because I don't know COBOL, but I could both demonstrate a solution in another language and learn COBOL at a later date, I would still FAIL?

Re:Yeah, and ....? (1)

lgw (121541) | about 2 months ago | (#47584569)

There hasn't been anything new in CS since the 80s.

No really.

Nothiing.

AJAX was new. Used to be the terminal and back-end would only exchange data when you hit the xmit key, and of course the web re-invented this pattern adding nothing new, but then it actually went a step beyond. Of course, it's mostly abused in horrible ways to punish the user for the crime of being a customer, but then, what tool isn't?

Other than that, yup, mostly re-inventing of the wheel by people young enough not to be there for the last trip round.

I agree (1)

Anonymous Coward | about 2 months ago | (#47584015)

As a (mostly) hobby programmer I agree. Tool complexity is much too high. Programming languages and widgets toolkits are relatively fine, though (except for intentionally blown up languages like Java). The real problem are the tools for building, packaging and deployment. For example, I was considering to package a cross-platform application I wrote for the Ubuntu "app store" but gave up after studying the in my point of view fairly complicated rules and process. Kudos to all package and repository maintainers, it seems to take more time packaging an application than actually coding it. I also admire anyone who masters the complete GNU toolchain, which, again, seems to require more programming in incomplete domain-specific languages with arcane syntax than writing the program to be built.

I wish I had more time. Busy people like me need tools that allow them to write an application, copy&paste the docs and icon images and produce the executables for all major platforms. Some commercial toolkits come close to that, but unfortunately even those that once have started as affordable shareware have become ridiculously expensive.

However, I'm not convinced that the reason for that state of the art is featuritis. Having the features never hurts, it's the way the tools have to be configured. Too many authors of programming tools do not know or do not seem to care much about ease of usability.

Not just programming tools have usability deficiencies, though. I'm afraid GNU/Linux, which I use daily for work and fun, has similar problems. For example, Ubuntu frequently bothers me with a dialog asking me whether I want to give "an application" access the default key chain without telling me which one. How could you decide whether an application should be allowed to access your passwords when you don't even know which one? This is not only insecure, it makes no sense at all.

Yeah, well, enough whining for today ... it's not that bad, is it ;)

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

gestalt_n_pepper (991155) | about 2 months ago | (#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.

Re:"Featuritis" in the whole computing ecosystem (0)

Anonymous Coward | about 2 months ago | (#47584127)

I agree at the annoyance of having an endless stream of half baked tools that are never upgraded.
He is complaining that people are adding new tools and un-needed features and this impedes him in the joy of building his new tools and features.
He seems to assume his work is necessary and not a blight on someone' happiness.

Re:"Featuritis" in the whole computing ecosystem (0)

Anonymous Coward | about 2 months ago | (#47584605)

I'm learning how to program Swift!

Neener, neener, neener!

Re:"Featuritis" in the whole computing ecosystem (1)

gestalt_n_pepper (991155) | about 2 months ago | (#47584701)

Lucky you! I'm sure this will terribly valuable in 20 years time, much like my ability to do code typesetting on a Compugraphic Quadex 5000 using Forth.

Much worse than you think. (0)

Anonymous Coward | about 2 months ago | (#47584141)

Ah, the trending tech phenomenon. Here's the harsh truth. Not only are most of the new tools just rehash of existing implementations coming to you at the cost of days learning and months of perfecting new languages, APIs and paradigms, but depending on your industry you may have an uphill battle convincing those in power that it's not worth the effort. Developers are tribe followers. We gravitate to passion and other developers who rise up with (in reality) mundane solutions that have been nicely packaged with pretty websites and a GitHub endpoint (all of this done to champion and advance the career of the originator in most cases who dreams of one day taking the podium at his own OSCON session) We need a cause.get behind and perhaps most importantly we need to feel as if the tools and patterns we use are always moving us forward so that we can feel of value and sell our value to the Fortune 500 companies and start ups that can afford the latest trending tech. We need to be able to convince people what we offer is giving them some strategic advantage. Almost always it is not. In most cases it adds more risk and cost to projects.But this isn't going away. If anything it's getting worse. As developers, sure we all genuinely want new tools to enable us to do the job faster but qualifying the good from the bad can be difficult and can honestly make you begin to hate doing this sort of work professionally in teams.

Assembler only - One Coder - No backdoors. (2)

MindPrison (864299) | about 2 months ago | (#47584179)

Yep, I live in the stone ages, but at least I know every corner of my systems.

Re:Assembler only - One Coder - No backdoors. (1)

MindPrison (864299) | about 2 months ago | (#47584199)

...and btw, those systems are OFFLINE ALWAYS! ;)

Re:Assembler only - One Coder - No backdoors. (1)

NoImNotNineVolt (832851) | about 2 months ago | (#47584827)

*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!

Change for the sake of change (0)

Anonymous Coward | about 2 months ago | (#47584219)

The trend I've noticed is that innovation has almost stopped, and has been replaced by change for the sake of change. Instead of innovating, people seem to be breaking things just to release new versions. Did Firefox really need to move View/Source? Did the atrocities of Gnome 3, Firefox 29, Windows 8, etc really need to happen? Was anything improved? Firefox breaks so badly that people write extensions to put it back the way it was - isn't that a clue that churn is getting too much?

The last few years have been filled with churn, but with no real progress. The number of programming languages is getting silly. (And they're starting to die as soon as they're announced, which is good. Seen any articles on Dart lately?) The way frameworks and libraries break themselves with each release is silly. The churn among frameworks is also getting to be ridiculous. How many MVC frameworks does Java really need? Ant is awesome, it works and can do everything, but there is a maniacal drive to throw it out and replace it. The much lesser Maven is taking over, and Google want to destroy the Android build process by inventing some lesser tool.

The point is that as an industry, we're reinventing the wheel every few years. That means endlessly trying to keep up with learning the same thing over and over again. Doing that is a silly waste of time, especially since there is a "shortage" of skilled workers. If there is a "shortage" the expedient thing to do is get back to industry standards so skills are portable. Why does every company have its own silo of technologies?

And as an industry, there is a "skills shortage" because if you don't know the MVC flavor of the month or whatever, you don't have the skills to do the job, even though picking up the skills is trivial because it's all the same stuff in a slightly different form. All anyone looks at is buzzwords on a resume, though, and we have to get beyond that to seeing what skills people have in software design, construction, and implementation.

All I'm saying is that no one can think of anything new to do, so they just churn out change for the sake of change just to have new releases. When it comes to tools and languages, the industry needs to get back to standards so that skills are portable.

Not again... (0)

Anonymous Coward | about 2 months ago | (#47584291)

Look ma! It's the latest entry in the Ask Slashdot bi-monthly series "What's the best way of getting back to coding"!

vi, c, make, sh (1)

turgid (580780) | about 2 months ago | (#47584669)

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.

UI has improved? (1)

epyT-R (613989) | about 2 months ago | (#47584745)

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 simplest tasks.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>