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!

'Just Let Me Code!'

Soulskill posted about 2 months ago | from the not-until-you-finish-your-vegetables dept.

Programming 372

An anonymous reader writes: Andrew Binstock has an article about the ever-increasing complexity required to write code. He says, "I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. ... The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. ... Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity."

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

Code the way you want... (5, Insightful)

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

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

He who pays the piper calls the tune...

Re:Code the way you want... (5, Insightful)

Sowelu (713889) | about 2 months ago | (#47518163)

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

Re:Code the way you want... (3, Informative)

i kan reed (749298) | about 2 months ago | (#47518257)

I'm kinda surprised you chose C# as:

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

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

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

Re:Code the way you want... (1)

gutnor (872759) | about 2 months ago | (#47518503)

C# is radically different. Your IDE, your test env, your OS, your frameworks, language features, ... all those are different enough so that you will not feel at work when coding with it.

Re:Code the way you want... (4, Interesting)

Sowelu (713889) | about 2 months ago | (#47518507)

Well, it's different in the ways that make a difference for me...which weirdly enough are "different syntactic sugar" and "a different IDE". It's not as different as it could be, but it does have the advantage of keeping me sharp in the same concepts Java uses as well. I don't have to yell at Eclipse when I'm at home, and I get legit excited when I can play with Linq. (What has my life become...) And that's enough to prevent burnout. But, projectwise, instead of writing backend server components for internet things, I'm writing one big program that decompiles an old retro game and extracts its map and graphics data with a nice graphical client. It feels too big for python. I guess at this point, "small projects" means "things that are not fifty-dev enterprise software things". Small enough that one developer can actually do it all.

I can say that being one dev in control of an entire hobby project makes me a better unit tester (seriously, what company actually follows its own internal UT guidelines) and is great for architecture experience, if you are a midlevel SDE on the rise.

There's probably something positive intellectually about having two languages with slightly different data structures; when you try to solve a problem the same way and are forced to make minor changes, you might find optimizations that are useful in both languages.

My hobby language used to be Multi-User Forth. That got tedious.

Re:Code the way you want... (0)

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

Heh, thanks for this one. I've been doing a lot of my hobby coding in Java/Android as well as working full time in it. It's a lot of fun, but it does get to be a bit of burn out. The only thing that's really made it worth while is that everything I've writen in my blog/code on the side has been separate from any kind of stuff I actually do at work. I just started that Udacity course on AppEngine though, so that should break the monotony a bit while also giving me a small bit of backend knowledge.

Re:Code the way you want... (1)

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

PHP at work. HHVM+Hack at home ;-)

I am **very**, extremely happy with this arrangement ;-)

Re:Code the way you want... (4, Interesting)

SQLGuru (980662) | about 2 months ago | (#47518235)

I finally got to code when I switched from being an employee to being a consultant. My bill rate is high enough that they would rather me work than to get bogged down in meetings. Not saying it will work for everyone, but it worked for me. I've done more REAL work in the past two or three years than I did in the previous 10.

Re:Code the way you want... (4, Insightful)

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

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

Re:Code the way you want... (2)

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

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

Re:Code the way you want... (0)

Shortguy881 (2883333) | about 2 months ago | (#47518381)

Yeah, this guy just likes to complain.

If you dont like where you work, work somewhere else (all those who think thats impossible are bad coders or wouldn't take a pay decrease to be happy at work).

If you can't find a place that suits you, start your own. I have my own company working on artificial intelligence programs. Granted, I do it in my spare time and am currently the only employee, but I am enjoying it.

Just let me do brain surgery! (1, Insightful)

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

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

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

Re: Just let me do brain surgery! (5, Insightful)

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

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

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

Re: Just let me do brain surgery! (1)

cavtroop (859432) | about 2 months ago | (#47518573)

Programmers are just cogs in a machine nowadays. Comparing them to brain surgeons is laughable at best.

I get the analogy you're trying to do, but it's not how businesses view programmers anymore.

Re:Just let me do brain surgery! (3, Informative)

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

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

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

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

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

Yeah... (0)

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

If you want to 'just code' with no controls, then take it up as a hobby in your spare time.

Who is stopping him? (2, Insightful)

Karmashock (2415832) | about 2 months ago | (#47517949)

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

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

Re:Who is stopping him? (2)

nblender (741424) | about 2 months ago | (#47518009)

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

I think what the submitter wants is to be able to 'hack' like the old days. Either find a different job or sign up with some open source gig and hack to your heart's desire.

Re:Who is stopping him? (2, Insightful)

Karmashock (2415832) | about 2 months ago | (#47518181)

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

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

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

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

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

So what is left?

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

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

Re:Who is stopping him? (1)

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

>Is it harder to code in windows then in DOS?

Definitely not. In DOS I had to manually draw every UI element. With modern tools I can focus on the code that actually does work while Windows handles the UI elements.

Re:Who is stopping him? (1)

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

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

Re:Who is stopping him? (1)

Forever Wondering (2506940) | about 2 months ago | (#47518433)

IMO, cmd.com is [also] a four letter word :)

Re:Who is stopping him? (4, Insightful)

Matheus (586080) | about 2 months ago | (#47518047)

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

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

Re:Who is stopping him? (2, Funny)

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

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

Re:Who is stopping him? (2, Funny)

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

Lol, I like this complaining format:

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

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

Indeed (0)

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

Simplifying a process is great, but you cannot simplify past the problem's intrinsic complexity. Pounding your fist saying "these tools are too complicated" doesn't reduce the number of use cases they have to support.

So, the article author got a nice taste of the real world. Time to adapt to the realities of the industry, or leave it.

Re: Who is stopping him? (1)

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

We can see from your comment that you do not know what he is talking about.

Re:Who is stopping him? (0)

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

Dude, the fucking internet. Have you tried to write a webapp and manage the "full stack" for it lately?

Re:Who is stopping him? (3, Interesting)

TheGratefulNet (143330) | about 2 months ago | (#47518321)

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

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

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

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

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

Re:Who is stopping him? (-1, Flamebait)

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

You're the problem with the software industry. You are why it won't grow up into a real engineering discipline. You are why most code released is crap. You are why spec and finished product do not match.

I've been coding since 79. It's not more difficult today then it was then, if you do proper engineering.

Sure it's harder to slap out a pile of crap in that environment. Good.
Grow up.

Re:Who is stopping him? (1)

Sperbels (1008585) | about 2 months ago | (#47518577)

so I don't think we made any real progress

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

Re:Who is stopping him? (5, Insightful)

Motherfucking Shit (636021) | about 2 months ago | (#47518357)

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

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

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

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

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

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

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

"Just let me build a bridge!" (5, Insightful)

horm (2802801) | about 2 months ago | (#47517955)

Engineering any complex system requires a significant amount of planning and management overhead. When you want to build a bridge, you don't just throw a bunch of construction workers at it and trust them to make the best judgements, even though you might trust each one of them individually to build a sawhorse or something equally trivial.

Re:"Just let me build a bridge!" (5, Insightful)

aix tom (902140) | about 2 months ago | (#47518183)

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

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

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

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

Re:"Just let me build a bridge!" (1)

niftymitch (1625721) | about 2 months ago | (#47518193)

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

Engineering vs. building is an interesting distinction.

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

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

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

Then there are bridges over puddles and other bridges over 1000 foot canyons. In one case
you get wet feet and soggy shoes...

Analogies are poor... (1)

Junta (36770) | about 2 months ago | (#47518227)

Yes, if a project gets to be large, then you need careful process. There are a few flaws though:
1. A large proportion of the time, you are doing something far less complex and/or dangerous than bridge building. There are people who insist that for something akin to 'hello world' test cases must be written, everyone must use a bloated IDE, all code must be in version control managed by some project hosting site with issue tracking, wiki, code review, and continuous integration. Sure, there can be value in that stuff, but there is cost. Frequently the cost outweighs the value for simple utilities (git and test cases are generally tolerable, but venture far into mandates about IDEs and project management and it can get nasty).. One example for me was for a quick 2 or 3 line C program people might fire up visual studio, and end up with a 'project' with a lot more metadata than the application itself, when using the microsoft SDK by itself with notepad would have been just as good (in linux the 'just run gcc' can be taken for granted, in MS you don't have a compiler and most laypersons don't even realize you can get SDK without visual studio, so I used that example since I see visual studio project files for the dumbest stuff).

2. A great deal of the tools are frankly half-assed. Particularly when it comes to deploying the tools. Once deployed they work about 80% of the time, but then fall over and block progress while someone figures out why the tooling fell over. A lot of these development tools got to the point where the authors of them could use it and that was about it. One who understands every nook and cranny and can quickly recover given a stack trace doesn't feel as strongly about doing the other '1%' of work to make it easy for others to deploy and administrate.

Re:"Just let me build a bridge!" (4, Insightful)

Qzukk (229616) | about 2 months ago | (#47518245)

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

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

Re:"Just let me build a bridge!" (0)

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

To be fair, a lot of software is extremely overengineered and underdeveloped. If you've ever had the misfortune of hearing a software engineering lecture, you immediately understand how some people can be proud of software that any sane programmer from two decades ago would throw out to start over. And he'd end up with something that has better time and memory complexity and fewer bugs and is easier to understand. But none of the "software engineers" could run any tests on it, so they'd throw it out and return to the bloated mess they "engineered".

Re:"Just let me build a bridge!" (4, Interesting)

Impy the Impiuos Imp (442658) | about 2 months ago | (#47518365)

I recall attending a Microsoft Visual C++ Developer's Conference about 15 years ago, when COM and interfaces were all the new rage. I recall one MS guy giving a speech about the complexity of developing with it, bragging, "If it came down to usability for developers or functionality, we chose functionality."

I knew then I was dealing not with real engineers but with clowns proud of a college project.

Re:"Just let me build a bridge!" (1)

istartedi (132515) | about 2 months ago | (#47518315)

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

Re:"Just let me build a bridge!" (1)

GiganticLyingMouth (1691940) | about 2 months ago | (#47518345)

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

n00b (0, Informative)

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

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

For given values of useful (0)

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

Things like documentation and version control make your work a lot more usable.

For trivial programming (1)

just_another_sean (919159) | about 2 months ago | (#47517979)

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

Again, I'm talking "Coding for fun, hobby, learning" here, just simple stuff. If it's a business app or something where the subject matter is complex than my feeling is the tools are still more helpful in overcoming that complexity than having to do everything from the bottom up.

Re:For trivial programming (0)

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

I disagree. For complex systems people tend to rely too heavily on the toolset to manage the complexity. But the complexity is better met by modularity of the system. Rather than developing an enormous C++ application in a single repository, start farming things out into separate libraries and maintain them as separate libraries--which means minimal dependencies sometimes requiring some moderate amount of duplication.

People spend too much time trying to abstract _everything_. The problem with that approach is that it's not manageable to apply such rules across large scales. Likewise, they try to minimize everything. That leads to excessive reuse of code (that's right, I said reuse, not duplication!). Excessive reuse of code means that small changes and bugs can ripple through a project. If you have two functions which do identical things, best practice says to merge them and reuse the same function everywhere. But in _practice_ if you do that too much you end up with complex interdependencies.

Take, for example, the "utility" library that everybody writes. They put all their tree, list, hash, and string operations into a shared library. It slowly grows over time. Eventually you're making design decisions on some project based on the limitations of that shared component. In actuality, such simple data structures should be the last thing you need to worry about duplicating. It's precisely the kind of thing you can copy+paste, because that logic isn't going to change. Python, Perl, Java, Ruby, et al don't share a libtree or libstrops library, even though they all implement almost exactly the same algorithms in identical use cases. They do often share use of ICU (unicode library). That's not a coincidence.

My development environment is GNU Make (not autotools! Just GNU Make.), joe (Joe's Own Editor), Git (if I have a choice although it's not that big of an issue because I don't care about IDE support), and a POSIX environment. Being well versed and well practiced in those things makes it easy for me to develop in most environments and most languages.

Kill yourself (-1)

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

Welcome to the fucked up world. You should kill yourself. Kill yourself now. It is the only option.

We need to talk about your TPS reports (4, Funny)

Joe_Dragon (2206452) | about 2 months ago | (#47517987)

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

Re:We need to talk about your TPS reports (1)

ArhcAngel (247594) | about 2 months ago | (#47518255)

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

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

Re:We need to talk about your TPS reports (1)

Joe_Dragon (2206452) | about 2 months ago | (#47518581)

you are still printing them? that is for the old job codes and not the new ones that are just E-forms

Bicycles and Jets (3, Insightful)

bill_mcgonigle (4333) | about 2 months ago | (#47517995)

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

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

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

So what is the solution? (1)

sandytaru (1158959) | about 2 months ago | (#47518023)

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

Honestly, I think developers on big teams have it easier. Part of my job is to do some of the less exciting operational stuff so that they can spend more time coding. (We unfortunately lump in the build process with coding, even though it's not that sexy.)

Re:So what is the solution? (1)

Krishnoid (984597) | about 2 months ago | (#47518351)

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

That's my text editor, you insensitive clod!

Cue the "artist" vs. the "engineer" (5, Insightful)

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

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

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

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

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

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

Re:Cue the "artist" vs. the "engineer" (3, Insightful)

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

You got that right....

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

There are two ways to avoid all this...

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

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

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

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

No Surprise (1)

digitalPhant0m (1424687) | about 2 months ago | (#47518035)

This is what happens when doing what you love turns into a job/career no matter what the industry.

Re:No Surprise (0)

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

This is what happens when doing what you love turns into a job/career no matter what the industry.

W. O. R. K. is four letters for a reason...

Shocking (-1)

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

Wait, I thought the Free Market was the ultimate creation of humanity and efficient in all manners, that inefficiency was only the realm of lowly government efforts. Are you telling me inefficiency exists in most if not all aspects of life, including the tech industry? :o

best hacker !! (0)

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

I got into programming because I want to be the best hacker in the world.

Thats why I stock MILLIONS of retro-components... (3, Insightful)

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

...Yep, got a pretty solid collection of those components, yesterdays micro controllers, CPU, Ram, Rom, Transistors, Tubes, Electrolytic Caps, Resistors, Varistors, Nuvistors and whatnotstors...

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

I do feel the pain of many of todays youngsters who have to go trough extreme learning curves just to get into "the game" from scratch, not easy. Everything is specialized and we literally have no jack-of-all-trades coders anymore, pity...that's what we need IMHO.

obligatory car analogy summary (1)

NemoinSpace (1118137) | about 2 months ago | (#47518081)

Yes, we have taken the hand crank off engines long ago.
And I miss them.

And here I thought it got easier... (2, Insightful)

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

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

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

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

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

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

web development, and java ee in particular (1)

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

This certainly seems the case for web dev and java ee. I am not as sure it holds true in other software realms.

Web dev is the klugiest of environments and it's made worse and proudly so by web devs.

Re:web development, and java ee in particular (2)

Daniel Hoffmann (2902427) | about 2 months ago | (#47518185)

I could throw so many acronyms and language/framework names at you I personally use in a single project that you would want to kill yourself before going into corporate web-dev. And I don't even use Java EE, I use Spring (which is still a beast, but not as bad as Java EE.)

Re:web development, and java ee in particular (0)

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

I worked at a place (~13 years ago...) that insisted my object be an EJB and I that alone made me want to kill myself.

Tools not the real problem (1)

PerlPunk (548551) | about 2 months ago | (#47518095)

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

Documentation (5, Informative)

pooh666 (624584) | about 2 months ago | (#47518099)

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

Re:Documentation (3, Funny)

Tablizer (95088) | about 2 months ago | (#47518453)

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

Re:Documentation (0, Interesting)

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

That's because Node.js is an ugly hack built on an ugly language, both of which have piss-poor support for concurrency and parallelization. Callback continuations are idiotic. But it's the only way to do concurrency in Javascript because the language's evolution is constrained by the existing JIT implementations, which cannot cleanly support fibers or coroutines. (And in a browser context you simply don't want massively concurrent execution of contexts within a web page, anyhow. Yet in a server environment it's the precise thing you want most!)

I manage a small Lua library which is simpler, cleaner, smaller, more useful (coroutines instead of callbacks, condition variables instead of promises, although I've implemented promises using condition variables and coroutines), infinitely easier to extend (Lua is unsurpassed this way), and more portable (O(1) polling on all BSDs, OS X, Linux, and Solaris; signal polling on all; file change notification on all; among other facilities) using Lua. LuaJIT is faster than V8, although most web apps aren't bottlenecked by the things that a JIT accelerates. In any event the library builds as a module for LuaJIT, PUC Lua 5.2, and PUC Lua 5.3.

The last piece to my puzzle is implementing a networked module loader. I can seamlessly interpose the require() function and download modules on-the-fly, maintaining a local cache. Requiring users to pre-install modules a la NPM is so 1990s. With my library you'll be able to use any module you care about without worrying about installation or removal. I can even download updates to modules in the background, so that security updates or bug fixes can be applied to running instances, as long as the module is careful about state management.

See http://25thandclement.com/~william/projects/cqueues.html, which is the low-level library I'm building the project around. It has zero dependencies, building cleanly on OS X, NetBSD, FreeBSD, OpenBSD, Linux, and Solaris 11 using the stock environment (libc and OpenSSL).

was with op until the end... (0)

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

Everything except simplicity.

I posit that the reason most of the tools suck is they try to make things TOO simple. examples being ui toolkits like yui or jquery-ui. Their object models may be innovative for allowing complex apps with terse code, but what if those terse code examples don't do what you want? the documentation is abysmal, and invevitably innaplicable to the version you have. What if you're trying to traverse your way up the callstack to solve the problem for yourself? by the tenth 4-line function up the stack surely it becomes obvious!
The bottom line is they try to hide everything from the "user" (the user of the toolkit is the developer), to make it "easy". but it never is.

The price you pay (4, Insightful)

petes_PoV (912422) | about 2 months ago | (#47518131)

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

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

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

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

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

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

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

Re:The price you pay (1)

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

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

No, it doesn't. Only if you're an awful programmer. Such checks can be inserted without going beyond a few hundred lines of code.

Re:The price you pay (0)

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

Such checks can be inserted without going beyond a few hundred lines of code.

Your code gave me an error message that it did not like my date format. You are an awful programmer.</user>

Re:The price you pay (2)

petes_PoV (912422) | about 2 months ago | (#47518333)

Such checks can be inserted without going beyond a few hundred lines of code

And then the next guy writes their own set of checks, which work slightly differently and check different things and in a different order. So both of you have spent time writing essentially, the same thing. - And maybe even spent even longer testing it and occasionally documenting it too. OK, maybe that last one''s a stretch. Nobody bothers to document "simple" programs, since we all know the code IS the documentation and any good programmer can work out what is going on (are they still teaching that garbage?)

And then when there's a change to the data formats, or a migration to a new environment, instead of swapping out one library of standard code - every single soddin' "simple" program has to be checked, re-tested and debugged.

So no. People who are still doing this sort of thing, even though the industry has been suffering from their intellectual laziness for decades, shouldn't be allowed to develop commercial code.

Boy, do I hear you! (4, Insightful)

QilessQi (2044624) | about 2 months ago | (#47518137)

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

Just let me cut!

The complexity has to go somewhere (4, Interesting)

Krishnoid (984597) | about 2 months ago | (#47518153)

As things become more powerful, you can't just wish away the complexity [wikipedia.org] . Maybe you can hide it in one of these 'shibboleth' things mentioned in the summary. That sounds big enough to hide things. Or maybe we could just use describe things more clearly -- but that's crazy talk.

Grow Up (0)

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

Yes, when we were children we rode bicycles and skateboards and such.
Now we drive cars replete with traffic jams, speeding tickets and such.

Writing code for operational use involves a lot of people and intricacies. Which means systems, checking and cross-checking. You will not get away from that.
There is the same issue with mechanical and electrical design.

Grow up and do the work you need to do which includes some of the stuff you don't like doing but is still necessary.

Eat your damn broccoli!

vi and arduino (2)

cptdondo (59460) | about 2 months ago | (#47518165)

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

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

Reality? (0)

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

So basically the author is just complaining about that his job doesn't consist of getting to write some small C++ programs without planning, documentation, and QA?

Perhaps he should get another job and keep coding as a hobby?

the problem is not coding, but coding well. (5, Informative)

nimbius (983462) | about 2 months ago | (#47518169)

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

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

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

Git Rid of the Java EE Stack and Go Node. (0)

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

I feel this authors pain.

I have been doing Node and Mongo development; 90% easier, 90% faster, 90% cheaper, and 100% enjoyable.

Gave up the below stack. The Java development stack has become way too complex, and expensive (both mentally and monetarily )

"Just say NO"
Java EE stack - Application Developer, DBA,

        System Admin,

        Security, WAS Admin,

        Build Coordinator,

        Deployment manager

- JSTL
- MyFaces
- Spring
- Hibernate
- DB Connectors
- Application Server

        -- JMS SOAP EJB CORBA

        -- Naming Directory

        -- JASS Security
- Source Control

Re:Git Rid of the Java EE Stack and Go Node. (2)

Daniel Hoffmann (2902427) | about 2 months ago | (#47518325)

I agree, the Java stack in general is way too big and this is from a guy that does Java development with the Spring framework (not as bad as JavaEE.)

But Java does have one big advantage: It can do anything

Need to connect to some ancient database? There is a JDBC driver for that.
Need to dynamically create a new excel spreadsheet, PDF, word document and so on? There is a library for that.
Need to talk with some bizarre web service that uses some kind of binary format? Probably there is a driver for that.

Unfortunately for corporate development you really need this kind of flexibility, that is why you don't see Ruby/Python/Node too much in the industry. Even Python (which has a very good set of libraries) comes short in many areas.

Sure you could write your own driver for Node, but:
a) You are not that good with node to do it (because it is new and your devs are just learning it)
b) It will take more time to get it stable than the thing you are trying to build in the first place or it will be buggy as hell

Sad but true, the language really doesn't matter much these days, what matters most is what the language can talk with and how hard it is to make that language talk. It is getting better though, web-services for example are standardizing in REST APIs.

Re:Git Rid of the Java EE Stack and Go Node. (1)

Shortguy881 (2883333) | about 2 months ago | (#47518391)

Yes, because what the world needs is more Javascript

Just some pointers to where you can go (2)

Daniel Hoffmann (2902427) | about 2 months ago | (#47518197)

void *unemployment;
struct hell *reality;

It's a brave new world (1)

jeffmeden (135043) | about 2 months ago | (#47518209)

"What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost."

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

development is mainstream now (0)

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

The recent influx of non-programmers getting jobs in development has caused this. They don't want to write code, because they know they are under skilled and have no interest in learning more. So they push for more process and paperwork that nobody reads. That fills their day and management can't say they are slow.

From an Ops point of view (1)

chispito (1870390) | about 2 months ago | (#47518231)

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

I own my scripted 'products' and I reap the full benefits of them.

He has a point (0)

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

I think he has a point. While some tools give a good deal of benefit for their added complixity, there are a lot of complex coding tools out there that, on large projects, are required or requested. For example, let's say I want to contribute to project XYZ. This project does not supply tarballs and is hosted on github. Oh and they only accept pull requests, not mailed in patches. This means the would-be coder needs to learn how to use git and how to use the github-specific features to contribute even a tiny patch.

The same sort of thing crops up with projects which practically require (or expect) developers use a specific GUI. How many times have we seen suggestions on how to get invovled with a project which start with: 1. Install Eclipse. 2. Install these extensions. 3. Install this emulator. 4. Install git and check out the code....

If this guy is working on his own, one-man project he can do it whatever way he wants (though heaven help him if he needs to find documentation on open source libraries). However, if he wants to contribute to a larger, existing project he almost certainly will need a lot of extra tools just to checkout the code and compile it. It's damn frustrating.

I find the opposite... (1)

jmintha (56956) | about 2 months ago | (#47518259)

I guess it depends on what you want to achieve, but I find web based development has made it easier to do that fun kind of programming. I grab a framework (python/django currently) and I can have a fully working interactive application in 10 minutes or so. Spend a couple hours more, and I've got it polished with fancy javascript. No need to write entire client interfaces, client server protocols, etc.

Wha? (1)

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

Do we now allow random rants? What the hell is this?

Companies pushing tools (0)

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

Companies who offer development and server tools need to sell big, expensive, heavyweight products in order to charge big prices.

That means Java an all the associated alphabet soup - ESB, SOA, XML, blah, blah, blah. They'll sell the VPs on enterprise ready, clustered, extensible crap that requires hundreds of hours of consultants just to install.

Now complicated? How 'bout all src in 6502 ASM? (2)

yayoubetcha (893774) | about 2 months ago | (#47518311)

Stop complaining! It's easier now then ever! How about modifying the source 6502 Assembly source code to a word-processing editor in the early 80s?

"Damn! What's the instruction to do a string fast string copy? Doh! No problem, I'll just look it up on Stackoverflow.com. Oops! That won't be there for about 3 decades!

I guess I'll just have to bitch about my problems on Slashdot.org. Doh! Again.... decades away.

At least there's USENET! Doh!

Re:Now complicated? How 'bout all src in 6502 ASM? (0)

gtall (79522) | about 2 months ago | (#47518441)

Yep, I used to walk 20 miles a day just to pick up one processor instruction manual...in my bare feet...and then had to carry it back.

In the 80's, you had a few manuals on your desk and it was enough. Now you need the WWW just to hack your way through all the details to get something running. The systems were smaller back then, the languages were simpler, the assembly code was simpler. Nothing is simple any more.

Still possible to ride a bike (0)

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

It is still possible (to learn) to ride a bike today, you don't have to pilot a jumbo jet. It's just that riding a bike does not earn you so as cred as it did 15 years ago. On the other hand, writing an "open-source mobile app that, say, compares your distance traveled with its equivalent distance as the crow flies" would be next to impossible back then. Should you be able to pull off such a thing, you'd be the jumbo jet pilot before the jumbo's were invented yet.

Simplicity is out there (1)

allquixotic (1659805) | about 2 months ago | (#47518369)

Simplicity is out there; you just have to find it. Obviously, if you're writing a general-purpose operating system that has to use a minimum of resources, be nearly impervious from malicious attackers hitting it from all directions, scale to the largest workloads, and run on hardware ranging from smart watches to multi-petaflop supercomputers, it's not going to be simple. That's just the reality of it. Designing such a thing is no simple task. One size definitely does not fit all.

Relative simplicity in coding can still be found in line of business applications, workplace automation, that kind of thing. Basically, if you're writing a specific program that will only ever be used by your team of staff in a 10-person office, it's perfectly fine to hard-code a file path into your program code, or require a very specific version of Ruby or Java, or write a brittle 300-line function that could really use some refactoring to be more maintainable later. If you double-click it and it does its thing and exits, you're done -- no need to write unit tests, or roll it up into a redistributable .war or .ear, or test it on IRIX and Solaris to make sure the build system builds on anything, or transport yourself 5 years in the future and make sure it'll still run perfectly on Windows 10. There's just no need. If it breaks, you can fix it in an afternoon and no one will even notice it was broken.

It sounds like TFA author just wants an easy programming job in a back office or IT skunkworks somewhere. Which is fine -- we need people to do that, or the world wouldn't work. Not every piece of executable code ever written was intended, or should be intended, to work perfectly fine on an 81-bit microprocessor in a kerosene-powered cheese grater running System/360, and to support a user doing something totally out of the design scope with the code.

Are you writing general-purpose software that is for sale or freely available to be used in a vast number of diverse scenarios? If so, you need to somehow manage the complexity in order to support all those scenarios.

If you're not writing general-purpose software, you can strip out many of the layers of software engineering that you're taught in college these days, because much of it is designed to manage that complexity. If the complexity isn't there, and to the point doesn't NEED to be there, then the layers of bureaucracy and red tape and process are pointless and can be scrapped.

That's not to say it should be a total ad-hoc hackjob. You should still use version control, no matter what, for anything beyond a 1-line batch file that you could recreate from memory. But if your version control consists of a git repo sitting on your local hard drive, and you don't have any code review before you push, who cares? You're still a developer doing productive work.

Not everyone is Linus Torvalds. Not everyone has to write code that will stand the test of time and operate correctly in totally unforeseen contexts. It's needlessly expensive to make it so. IT skunkworks exists for a very good reason.

this is why i code in php (LAMP) (0)

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

haters gonna hate

disagree (1)

sonciwind (970454) | about 2 months ago | (#47518527)

You must work in one of those bloated, systematic corporate environments where the gears have all rusted. Switch to a small, dynamic company. Start your own business. Then you can have the best of both worlds, the coding and the tools. You'll get 10 times the "transformation into living presence" than you ever got, and all the luscious typing code into a computer you can stand.

Not the tools (1)

umdesch4 (3036737) | about 2 months ago | (#47518533)

It's the damned processes. Yesterday, I got a new Jira ticket to fix a query and provide the updated results in a file to the ticket submitter. I looked at the query, realized that I knew exactly what was wrong with it, and fixed it, dumped the results, and sent them to this guy. I then resolved and closed the ticket in about 5 minutes. I took a bit of heat for it, because I didn't follow the due process of prioritizing this task, determining whether or not it would go into the next sprint, assigning story points to it, creating subtasks, and providing time estimates for them. All told, probably about half an hour's worth of meeting time and overhead to do a 5 minute task. But how dare I bypass the process to get something simple done??!!

He's right (0)

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

Ask yourself how much time you spend nowadays glueing different frameworks together instead of working on the actual useful part of the project. This wasn't the case 10 years ago. If you find more and more programmers copy/pasting code from Google or Stackoverflow, it might be because they can (they're being asked to repeat the same monotonous work as many other people). That sort of duplication shouldn't be part of our daily life. Computers should be working for us, not the other way around.

Yes, no coding. No, problem is not tools (4, Insightful)

michaelmalak (91262) | about 2 months ago | (#47518565)

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

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

To address specifically the reasons identified by the author:

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

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?