'Just Let Me Code!' 372
An anonymous reader writes: Andrew Binstock has an article about the ever-increasing complexity required to write code. He says, "I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. ... The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. ... Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity."
Code the way you want... (Score:5, Insightful)
...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... (Score:5, Insightful)
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... (Score:4, Informative)
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: (Score:2)
Re:Code the way you want... (Score:5, Interesting)
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: (Score:3)
Good domain-specific tools are written as command-line utilities, and are even better if you wrote them yourself for your project.
Text editing (which includes syntax highlighting etc.) is also much better with a text editor.
Editors are also more flexible, scale better for large projects, and can do anything you need them to do.
An IDE is extremely constrained and won't work properly whenever you need to do something that wasn't planned by the developer who coded it.
Re: (Score:2)
When I heard the Learn’d Astronomer
Re:Code the way you want... (Score:5, Funny)
They will both become an obsession.
You will code all night long,
While you're singing a song,
That relates to your own retrogression!
[BURMA SHAVE]
Re: (Score:3)
Don't really agree, I often use the same languages at home as work and I prefer it that way because I'm more productive due to being intimately familiar with the technologies in question.
Most the work I've done in the last year has been C#, and I've been using it at home also. I'm much better off working like this than using say C++ for game development in my spare time because I can simply get more done. As an indie I'm not writing the latest and greatest FPS so C# with things like Unity, MonoGame and so f
Re:Code the way you want... (Score:5, Interesting)
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... (Score:4, Insightful)
Same here. I hire out people to go to my meetings for me. No joke. It works GREAT!
Re: (Score:3)
What's your point? The main theory behind being an employee or a consultant (doing work for others in exchange for compensation) is to get paid as much as possible while doing as little work as possible. (The opposite is true for your employer/client; they pay you as little as possible while getting as much work as they can out of you.) Consultants extract money from the "job creators" and return it to the economy. Even if they did no work at all, that extraction justifies their existence.
Re: (Score:3)
A true agile process has an incremental delivery schedule. Rather than building the full deliverable and delivering, it identifies milestones as deliverable product. For example: a waterfall process for building a car would intake requirements and output a car; an agile process would produce the platform for inspection by the customer, followed by the suspension system, the engine, the drive train, interior, and so on, in some useful order.
For a software product, this involves delivering partial funct
Re: (Score:3)
True, but that doesn't mean those paying aren't getting exactly what they asked for. Dumb corporate policies cost money.
If you can get a devkit, that is (Score:2)
If you can't find a place that suits you, start your own.
And watch suppliers decline to do business with your startup company because they don't like your lack of experience or they don't like where its office is located. For example, some makers of computing platforms lock down who's allowed to have a devkit, and they have a history of reserving devkits for the most experienced companies with traditional offices.
Re: (Score:3)
If you're developing on a platform as developer-hostile as that and you're locked into it so your business can't port to other platforms if necessary, I would submit that you have bigger strategic problems and long-term risks than merely being a small company. An arrangement like that is an axe hanging over the head of almost any size of company and you have absolutely no control over when it might fall.
(No, I don't develop iOS apps or write console games, despite occasionally getting enquiries in those fie
Who is stopping him? (Score:3, Insightful)
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: (Score:3)
Depending on the environment in which you work. Where I work, there are source code auditing tools you are required to run against your code to meet various customer-imposed requirements; there are code-review tools... There are hardware debuggers that are tied to irritating IDE's like Eclipse... There is a veritable cornucopia of mandated tools, none of which actually help me to write code, but exist to make some manager or customer happy.
I think what the submitter wants is to be able to 'hack' like the o
Re: (Score:3, Insightful)
Even considering all that, have a standard template that triggers all that crap and then build your little creative projects in subroutines.
Is it harder to code in windows then in DOS? you're a lot farther from the hardware in windows. There is a lot more going on. But you don't see most of it because its abstracted or hidden away and mostly it doesn't matter.
Do the same thing with all your debugging shit. Write a template that loads and manages all that shit so you can hack it like you want to while retain
Re: (Score:2)
Most tools have their own APIs and many have their own DSLs. You either must learn a new sub-language or you have to program them. In every direction, complexity is an insistent reality poised to take you away from the core development activity: coding.
Here you might say that your little coding projects and hacks need to be linked properly to these various systems and that can be a pain in the ass. But again... why are you doing that manually? Write a program or a script that automatically creates the links.
The problem here is that once "a program or a script" reaches some level of generality, configuring it becomes almost as hard as just creating the links yourself. Hence the reference to application programming interfaces (APIs) and domain-specific languages (DSLs) in the article.
DOS had libraries too (Score:3)
In DOS I had to manually draw every UI element.
Only in your first couple projects. By your third DOS project, you probably would have built up your own UI library.
But the big thing that DOS did better than Windows back in the early to mid 1990s was using all the features of the VGA. DOS applications could run in low definition (Mode 13h, Mode Y, and Mode X, with resolution of 320x200 to 320x240). This allowed updating the whole screen before Windows finished updating half of a 640x480 standard-definition screen. DOS could also use hardware scrolling
Re: (Score:2)
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: (Score:2)
IMO, cmd.com is [also] a four letter word :)
Re: (Score:2)
Re:Who is stopping him? (Score:5, Insightful)
Sounds more like a cranky dev who graduated looking forward to creating Interesting Things(tm) and found themselves in the wealth of jobs out there creating What People Will Pay You To Do(tm) and is trying to find something grander than his lack of interesting job opportunities to fault it on.
As stated: If you want to create something fun with simple tools THEN FREAKING DO IT! There is nothing in this world holding you back unless all you are willing to work on is what someone is paying you to do.
Re: (Score:2, Funny)
Yeah, I got into "computers" because I was looking forward to a subversive career in hacking into corporate systems and selling their secrets to their competitors and to undermining the US. Now we just crack systems so we can sell email addresses to guys pushing dick pills. Reality really sucks.
Re: (Score:2, Funny)
Lol, I like this complaining format:
Yeah, I got into [specialty] because I was looking forward to a [edgy adjective] career in [exciting application of specialty]. Now we just [boring application of specialty] so we can sell [boring application revenue stream]. Reality really sucks.
Example:
Yeah, I got into machining because I was looking forward to a fast paced career in aerospace manufacturing. Now we just mass produce injection molds so we can sell crappy plastic coffee makers on ebay. Reality really suck
Making a living; devkit suppliers (Score:2)
If you want to create something fun with simple tools THEN FREAKING DO IT! There is nothing in this world holding you back unless all you are willing to work on is what someone is paying you to do.
Then how does one "create something fun with simple tools" and still eat? Besides, even if you have an unrelated day job, how does one "create something fun with simple tools" if the tools have to interoperate with other tools that are made available only to established companies, as in the case of developing games and other applications that run on devices commonly connected to TVs?
Re: (Score:3)
Re:Who is stopping him? (Score:4, Interesting)
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: (Score:2)
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? (Score:5, Insightful)
I think the main reason why spec and finished product don't match is because "spec" is a moving target that never solidifies. Agile processes just make it worse by not even attempting to nail down requirements beforehand - "it's more important to be able to show progress than actually know what we're supposed to end up with, and don't you dare document anything because it's going to change anyway" along with the idea that it's okay to spend thousands of dollars completely rewriting stuff as the requirements continue to change. It's impossible to properly engineer a product when you don't even know what the product is in advance.
Re: (Score:3)
Requirements change. The most common reason is that the requirements are normally simply not known until the project is underway. There are exceptions; my wife liked working for accountants because they knew what they wanted ahead of time. However, most people don't know what they need until they see enough things they don't need. Good requirements analysis can help (and I have daydreamed of getting mob enforcers to do it - "Is ya gonna tell me what data you need here or is I gonna break your kneecap?"
Re:Who is stopping him? (Score:5, Insightful)
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.
Re: (Score:3)
I also expect to see the second coming of Jesus riding unicorns at that point. Beta is the new Gold Master
Re:Who is stopping him? (Score:4, Informative)
I believe he's bemoaning the complexity of frameworks and toolkits rather than the tools used to work with those frameworks and toolkits. Technically he's correct -- things are a lot more complex than they used to be for getting the most basic of tasks done.
But you know what? Business isn't interested in basic tasks any more. They want it secure. They want it scalable. They want a web front end, and a desktop client, and apps for Android and iOS. The days of the old "read billing file, produce accounting records" code have not gone away; those projects were just done 30-40 years ago and don't need to be rewritten, just tweaked from time to time to allow for changes in regulations such as tax law or liability.
Even the last company I worked for wasn't content with a mere rewrite and update of their core business with the new software -- they had a whole new plan of integrating another 5 or 10 vertical functionality features into the system (it was just an autodialer -- they wanted integrated CRM, push button customer calling, call answering, call forwarding, a full phone system with voice mail support and enhancements to the ever popular auto-answering system of branching menus and responses, and the ability to deploy the whole thing as a multi-client web service instead of deploying custom configured hardware to the client sites.)
The frameworks and toolkits have correspondingly become more complex in order to support those needs. Look at the transaction processing systems of old -- you'd buy a number of seperate products including a message queueing system, a report formatting tool, a database engine, and a transaction processor, each of which had their own APIs and documentation. Each tool was relatively simple, but getting them all coordinated and working together was hard as hell. Now you take JEE, buy just about any message processor and database you like, and it all largely works with the same API regardless of which vendor's tools you chose. So while the JEE framework is incredibly complex compared to a transaction processor of old, what it does in total is also saving you insane gobs of time integrating and debugging disparate products. So technically JEE is far simpler than things used to be, despite the ramp-up learning curve.
The same is true of every framework or toolkit I've used for over 10 years -- they tie together multiple vendors products consistently so that only small tweaks are needed to adapt to the vendor's products rather than whole-application re-writes if you decide to swap something out.
Hell, take a look at what I did with Java, six different vendor databases, and JDBC alone for http://msscodefactory.sourceforge.net [sourceforge.net]. The differences between each of those database integration layers are not subtle, but nor are they particularly arcane. All of the products have virtually the same feature set; there are just differences in how you use JDBC and stored procedures for each database. Compared to "the old days", it was a cake walk to do that integration and customization over the past 3-4 years. And remember I worked on that code by myself -- it wasn't a whole team of programmers dealing with the complexity. If one guy can produce that using standardized toolkits in 3-4 years, how can you say things are more complex than they were when it used to take a team of 100-150 programmers 2 years to produce something similar for one database?
"Just let me build a bridge!" (Score:5, Insightful)
Re:"Just let me build a bridge!" (Score:5, Insightful)
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!" (Score:4, Interesting)
those two people SHOULDN'T be the same person.
In my experience, that is the heart of what is wrong with a lot of software projects: it's considered taboo to do both architecting and developing.
The theory is obvious enough, but in practice an architect that is not implementing overlooks some very significant issues. The implementer has his hands tied because 'the architect said so' and the implementer trudges on also blindly unaware of anything beyond his little island.
The best teams I've been in have had everyone participate in architecting and development, with healthy amounts of communication.
The thing about construction projects is that they are simply so massive you need a horde of construction workers. In software development, we often like to *think* we are making something equally massive when in practice if we do need that many people working on it to get to the goal then it 99% of the time means we are doing something wrong in the first place. If we put hubris aside and realized that the scale isn't so grand as to require a trillion little dependencies and components, we produce good code. This doesn't mean the opposite situation of a gigantic monolithic blob is good, but there is a reasonable middle ground.
Re: (Score:2)
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
Analogies are poor... (Score:2)
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
Re: (Score:3)
My point was that in MS world, you don't have a compiler until you get the SDK (which most people don't even know exists), and most think you only get a compiler through visual studio, whereas in linux it is commonly already there or a 'yum install gcc' or 'apt-get install gcc' away. A *whole* lot of people assume visual studio is a hard requirement to develop with microsoft first-party toolchain and as such you end up with project files for really stupid crap.
Re:"Just let me build a bridge!" (Score:5, Insightful)
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: (Score:2)
This last post sort of hits the nail on the head.
Yes, complex projects need to be managed, or you end up with dogpiles like most of today's ERP stuff (and many others). But by managed I mean managed WELL.
Managed WELL does not mean all sorts of overhead and red tape that exist just because a clueless project manager doesn't know any other way than one-size-fits-all full-blown project management according to some textbook. It means using tools wisely as the project's needs demand, neither more nor less.
Re:"Just let me build a bridge!" (Score:5, Funny)
What about synergy? Where is the GOD-DAMNED synergy!? Oh shit, this project is totally going to fail.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
Not a bad analogy, but Engineering follows the rules of Physics and Chemistry, which were built on layers and layers of scientific thought and experiment. Hardly anyone writing code these days understands what's happening under the hood.
Disclaimer: I've been programming since 1965. I'm proud of the fact that I can create logic gates that will do medium to complex mathematics.
Programmers have become like lawyers: They are sometimes competent technicians but are not required to engage in original thought. We
Re: (Score:3)
We need thinkers who can define requirements precisely, designers who can describe processes to produce those results, and then turn the design (UML. Warnier-Orr, Flowchart, etc.) over to a generator
We already do this, that generator is called a compiler. By the time you have specified a design to the same detail as an engineer specifies a bridge you have already written all the code. Engineers specify a design down to every individual bolt. Software specifications do not design down the individual line of code. This is the difference between engineering and programming: in engineering when a design is completed then the object still has to be built, in programming when the design is completed then
Re:"Just let me build a bridge!" (Score:4, Interesting)
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.
For trivial programming (Score:2)
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
We need to talk about your TPS reports (Score:5, Funny)
It seems that you did not put the new cover letters on them.
Re: (Score:2)
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: (Score:2)
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 (Score:4, Insightful)
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? (Score:2)
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: (Score:2)
Some sort of mega-all-in-one SCM, IDE, build tool, project management software nightmare?
That's my text editor, you insensitive clod!
Re: (Score:2)
Yeah, sounds like EMACS except for not having an OS thrown in... but maybe they just forgot to mention that.
Cue the "artist" vs. the "engineer" (Score:5, Insightful)
This is a old song and dance. It's easy to create software, but it is difficult to create and maintain good software.
Apply Sturgeon's Law [wikipedia.org] and be done with it.
I'm tired of whiny youngsters, and not-so-young wimps who think they can program because they took a few classes, or got hired by a tech company who was desperate to hire anybody with even the slightest talent.
Like the whining by Phil Fish in Indie Game [indiegamethemovie.com] movie about it being hard to write video games. Duh.
Get over yourself, it's called work. Many people including many programmers have being doing it for several decades now.
Re: (Score:3, Insightful)
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
Thats why I stock MILLIONS of retro-components... (Score:4, Insightful)
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.
And here I thought it got easier... (Score:2, Insightful)
With new processors being absurdly faster than they were 10 years ago, writing programs has never been easier thanks to the plethora of scripting languages available today. It seems like a lot of the tools are easier than ever to use, or still in use (make). Text editors like SublimeText or gEdit can help alleviate some of the terminal based text editor fear in a more "Word" like environment.
IDEs can do some crazy shit with little or no knowledge of what's going on in the inside, just sit back and "enjoy" t
Tools not the real problem (Score:2)
Tools make it easier for project managers and execs to try to collect data from developers for compliance initiatives, and the additional (and often unnecessary) burden that places on a development team in turn compromises development efforts, including those not directly related to coding.
Documentation (Score:5, Informative)
Re:Documentation (Score:4, Funny)
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: (Score:2)
The price you pay (Score:5, Insightful)
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: (Score:3)
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 garbag
Re:The price you pay (Score:4, Insightful)
Not just teaching it, *practicing* it. My boss is a hardcore Agile fan, and his official stance is "out of date documentation is worse than no documentation, so don't spend any time documenting anything, and if you can't figure out why this 12-year-old code is doing something, find someone in the group that does". Nice, except none of the guys that actually wrote that cruft are still there, and reading code doesn't necessarily provide any insights as to the higher-level theory of operation when multiple modules work together. Then on top of that, he says "I don't want to see any research tasks in this sprint". So what, I'm supposed to know how this works by osmosis?
Boy, do I hear you! (Score:4, Insightful)
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 (Score:5, Interesting)
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.
vi and arduino (Score:3)
That's why I work with vi and arduino, or openwrt.... Much more fun, simple, and I can do almost anything I need done.
But yes, it's a fixie, not a jumbo jet. It's what I like doing, and I happen to make a living at stuff like that. If you are hired to build a jumbo jet, then you need jumbo tools and jumbo overhead. If you don't like it, scale down, hang up a shingle, and get a client. You might be surprised.
Comment removed (Score:5, Informative)
Just some pointers to where you can go (Score:3)
void *unemployment;
struct hell *reality;
It's a brave new world (Score:2)
"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.
From an Ops point of view (Score:2)
I own my scripted 'products' and I reap the full benefits of them.
Re: (Score:2)
Yes, no coding. No, problem is not tools (Score:5, Insightful)
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:
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.
Progress Begets Complexity (Score:2)
Developers do everything Tm (Score:2)
The fundamental problem is that developers do everything. Heck, even in companies where there are entire teams dedicated to the task, developers still up doing them.
Maybe it's just because organizations are short staffed, lack of training, lack of skilled specialization. I won't dwell on the causes. I'll just state the reality.
In some theoretical world, source control is handled by a separate team, environment setup is handled by a separate team, testing is handled by a separate team. Each of whom are skill
Consider Apple's latest Xcode IDE with Swift (Score:3)
This new language is as much fun to code in as Python without the pure-interpretive overhead. The latest Xcode includes a "playground" prototyping space that makes it easy to experiment with pure code, including library API calls, before cementing your work into the application framework of iOS or OS X. Right now it's a one-manufacturer language, and still beta, but something tells me it's going to spread.
Commodore 64 (Score:2)
part of my nostalgia for coding on the C64 is how you felt you could know everything about the box. There was a book, Mapping the C64 and C64C [amazon.com]. that told you about every single address on the computer. You felt you could get everything done with some pokes and peeks, or some machine language. (LDA anyone?).
Now, you can do more, but you don't feel you can push to the envelope of the hardware. How many classes does java add every release cycle? How often does CPAN turn over?
I think im not the only one wit
Engineered code vs. created code (Score:2)
If you have a project that's too big to fit into 1 person's head and you want it to work right and be maintainable, you either have to have a team of people who practically read each other's minds or you have to have a solid design and maintenance process.
Either that, or you have to accept that unless you get lucky or your code is hardly ever used, you will have problems down the line.
Having a lightweight or non-existent process is fine for projects that can stay in one person's head and which won't need to
Derive Joy from It? (Score:2)
If I was supposed to derive joy from it, I'd be paying my employer to do my job rather than the other way around. I'm being paid because I do it for their benefit, not for mine.
Go work for a bigger company (Score:3)
Source control, IDEs, build systems and bug trackers... are all very ancient tools that tend to make people more productive so they can spend more time coding... leaving me puzzled and confused by TFA's point.
He seems to be saying enabling infrastructure to manage a product lifecycle is more difficult or at least non-trivial vs. problem space itself... Suppose if your one of thousands of shops churning out proverbial flashlight and fart apps this could well be the case...otherwise it is hard to understand how it can be true. While supporting infrastructure can and does become very complex for large development efforts there are usually tooling peeps on staff who specialize in each subdomain.
What makes matters worse you go on to hate DSL's, use NoSQL databases... which leaves me little choice but to assume you hate everything good and nice.
Either that or you got screwed working for some grossly understaffed rinky dink company with reams of old code nobody understands who lied when they used the word "developer" in job description...LOL.. happens...a..lot.....
I laughed my way through this article (Score:3)
I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.
Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.
Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"
Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:
The long, laborious setup:
git init
Saving changes:
git add --all .
git commit -m "This is what I did."
Undoing changes before saving them:
git reset --hard
git clean -fd
Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.
Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!
FONC: Fundamentals of New Computing -- Alan Kay (Score:4, Insightful)
From: http://vpri.org/fonc_wiki/inde... [vpri.org]
---
We are faced with a need for significant action and the odds are stacked against us. Invention receives no attention, and innovation (even when incorrectly understood) receives lip service in the press but no current-day vehicle exists to to nurture it. This wiki is an open invitation for talented individuals to pool their energy and collaborate towards fundamentally changing computing.
Over the years many groups have debated how to make progress in computing. There were likely as many opinions as there were people in the debates. Nevertheless personal accounts suggest that initiatives were sometimes reduced to a handful and then pursued with vigour. Consider what could be achieved by following the same pattern today, with the added benefit of doing it as a virtual, distributed team.
Our goal could be to capture the significant ideas and initiatives that we have been exposed to, are aware of, or can discover, distil them into groups, reduce them to a handful of concepts worthy of vigorous exploration, and focus our efforts on these common ideas with the eventual aim of making substantial progress towards finding a common set of fundamentals of new computing.
---
See also: http://vpri.org/fonc_wiki/inde... [vpri.org]
A big focus of FONC was in reducing lots of complexity. Smalltalk shows what is possible... But in practice new languages and new standards often just add more complexity to the mix and what we often need are better tools for dealing with complexity. And community and trends mean a lot too, as does hireability and ubiquity and easy installability. So, again, in practice, I'm moving to JavaScript with conceptually simple backends (even in, yikes, PHP) -- inspired in part by Dan Ingall's own work with the Lively Kernel which shows what is possible as near-zero-effort-to-install JavaScript apps.
My own thoughts on FONC from 2010: :-)
"fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
https://www.mail-archive.com/f... [mail-archive.com]
---
Biology made a lot of progress by inventing the microscope -- and that was done way before it invented genetic engineering, and even before it understood there were bacteria around.
What are our computing microscopes now? What are our computing telescopes? Are debuggers crude computing microscopes? Are class hierarchy browsers and package managers and IDEs and web browsers crude computing telescopes?
Maybe we need to reinvent the computing microscope and computing telescope to help in trying to engineer better digital organisms via FONC? :-) Maybe it is more important to do it first? ...
It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)
---
Learn the UNIX Philosophy (Score:3)
It's an attempt to get the most "bang for the buck". Essentially you write lots of small programs which have limited and well defined functionality, then you hook them up any way you like. In fact taken to the extreme (as with Plan9) you can do anything with simple shell scripts.
BTW there are simpler developing environments out there which have a decent feature set, without the complexity of a C(++) toolchain. Lazarus is just one example of it. Of course you then loose flexibility. Lazarus, for example, is mostly suitable for GUI applications. Writing a webserver with it is hard. Of course it does GUI decently well, allowing you to have one codebase compiling from everything from your bog standard Linxux (GTK) over MacOSX, Android to even exotic platforms like Win32.
I would also like to point out (Score:3)
I would also like to point out that back when it was every coder did everything himself from scratch (i.e. the good old days), the actual products sucked. There was a lot of fun work to be done reinventing the wheel millions of times over, but when 99.9% of the wheels had serious flaws, it was pretty hard for the user of these wheels to get any real work done.
So it turns out that most programmers are terrible, and they think it's fun to reinvent the wheel, because wheels are the only thing (they think) they understand. They think learning new tools are "boring" or "stupid" but mainly because it's hard to do things in a way you aren't already used to and "hard" things are "stupid" to people that want to use the rationale that the only reason they might not understand something is if it's stupid. The smart programmers learn to use the tools because it actually makes more efficient use of the time spent programming.
There was a time when programmers complained that compilers were stupid because there was no need to write in a high level language when you could just write in assembly code instead.
The smart programmers weren't the ones that could read and write in assembly and didn't need high level languages. The smart ones were the ones who recognized that high level languages would make programming more efficient and created that tool.
Complexity as a virtue (Score:4, Insightful)
That's because in the 90's programming got more difficult, and programmers *liked* it. No more soccer moms entering the field because they heard it was a way to earn a decent wage.
Complexity makes programmers feel they can do things most people can't. So, they seek complex solutions. If it's not complex, it must not be the intelligent way to do it, since a lesser person could do the simpler thing.
They have it backwards, of course. The ability to reduce the complexity of a task is actually a higher skill.
Re: Just let me do brain surgery! (Score:5, Insightful)
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! (Score:5, Insightful)
Of course brain surgeons don't "just do" brain surgery .... in any surgery, there's a ton of pre-operative work, investigation, preparation, paperwork, practice, etc. No one just dives in and cuts open your head.... and just as no one administrator hovers over the scalpel's every move, no manager hovers over every keystroke, either.
Re: (Score:2)
Re: (Score:3)
Re: Just let me do brain surgery! (Score:4, Insightful)
The surgeon knows his job and does it with great freedom. He/She 'just do' brain surgery
Nobody would survive a brain surgery if a physician would have to go through the same hurdles as a professional programmer
Very true. By the same token, by the time your average programmer was done with your brain surgery, you'd have toenails growing out of your asshole for some inexplicable reason. "Oh, we'll fix that in the next surgery." *That* is why we have "clueless" administrators pre-approving their shit.
The brain surgeon has to be worried about malpractice lawsuits; the programmer does not. The brain surgeon requires board certification; the programmer does not. The brain surgeon requires twice the education and years of formal, on the job training before he is ever allowed to operate; your average programmer thinks he/she can write shit-hot code before they even graduate.
Re: Just let me do brain surgery! (Score:4, Insightful)
Programmers are just cogs in a machine nowadays.
Code monkeys are, and that's the way that managers who hire code monkeys like it.
There are plenty of programmers out there creating interesting and useful new software, and plenty of customers/clients willing to pay serious money for the value that software offers them without all the unnecessary bureaucratic overheads and middle management crap.
If you are a good programmer and professional in your general conduct, you owe it to yourself not to be a code monkey for anyone, IMHO. You have to be really, really unlucky with the time and place when your current gig(s) run out not to have better options in 2014.
Re: (Score:3, Informative)
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 s
doctors like single player systems (Score:3)
doctors like single player systems as they don't have to put up that much paper work and billing BS.
Re: (Score:3)
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: (Score:3)
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.
Unfort