Slashdot Mirror
'Just Let Me Code!'
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."
...just do it on your own time, and don't expect people to pay for it.
He who pays the piper calls the tune...
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.
If you want to 'just code' with no controls, then take it up as a hobby in your spare time.
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.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
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.
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.
Things like documentation and version control make your work a lot more usable.
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 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.
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
It seems that you did not put the new cover letters on them.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.)
Occasionally living proof of the Ballmer peak.
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 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 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.
This is what happens when doing what you love turns into a job/career no matter what the industry.
I got into programming because I want to be the best hacker in the world.
...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.
What this world is coming to - is for you and me to decide.
Yes, we have taken the hand crank off engines long ago.
And I miss them.
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.
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.
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.
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.
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 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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
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!
Koans and fables for the software engineer
As things become more powerful, you can't just wish away the complexity. 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.
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!
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.
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?
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.
Good people go to bed earlier.
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
void *unemployment;
struct hell *reality;
"What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost."
You can't exactly get everywhere you need to go via bicycle these days. Blame globalization.
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.
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.
XML is like violence. If it doesn't solve the problem, use more.
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.
The Daddy casts sleep on the Baby. The Baby resists!
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 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.
Do we now allow random rants? What the hell is this?
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.
Comment removed based on user account deletion
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; 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.
haters gonna hate
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.
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.
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.
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??!!
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, 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.
This guy sounds like a twentieth century doctor probably sounded as the medical field started to become highly specialized. There are few things in life in which we make progress and make things simpler at the same time. It's the reason that you can't see the ground anymore while looking into the engine compartment of your car and it's the reason that laws are more numerous and more complex than ever before. Sometimes it's nice to look back at the simpler times with nostalgia, but there's no going back, and even if you could, you would probably just come out of it with a greater appreciation for the lifestyle that is provided by these advances, even if it comes at the cost of significant complexity.
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.
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 skilled enough to tackle the challenges they face.
From what I hear from some of the 'older' folks who worked back in the day at places like Nortel, this is how it was done. I'm in Toronto, so there are a lot of such people around. I'm sure similar stories could be had from other companies.
Yet, in too many roles, Ive seen devs basically writing the test plans and cases; doing the job of the test team, which doesn't want to 'know' the product. They just want to execute a script. I've seen devs knowing more about the environment than the environment team. This is even in cases where there are dedicated teams for these functions. Sometimes devs are even creating and assigning tasks in agile environment because project management doesn't know how to break down the task.
Let me emphasize, I'm not criticizing people in test or environment. It is just what it is.
Due to so many factors, it's basically up to devs to do it all. We might be able to on some level as we're reasonably smart and investigative people, but on any large project, it eats away. Since the ultimate deliverable is what we produce, many of us take it on, probably when we shouldn't.
You won't find a brain surgeon doing Vasectomies.
You won't find a corporate lawyer in acquisitions doing divorce law.
Heck, it's rare to find an English teacher teaching calculus.
This is not to say they couldn't. I'm sure a brain surgeon could pick up what is needed to do a vasectomy given the training. But they won't just do it. That is part of being a professional is demanding professional conditions.
I've seen the software field continuously scale back on people and specialization to the point where a problem does seem complex and daunting the second something is not ideal.
Can we often hack by? Yes, but not without this great unknowing which kills the professional inside of me. Yes, I know I can setup an environment, change webserver configs, setup git, test things... but there should be dedicated people who know these well.
'Just Let me Code' might seem like a whiny statement from someone who wants work to be fun. But it really is a big problem when you look at it. Companies are understaffed and under-specialized and they're quite frankly spoiled by having a bunch of devs who are capable of hacking away at things to get them working.
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 to pan over a large virtual area without having to do the bit shifting bullcrap that plagued standard VGA mode back then. Both of these became less relevant, however, as CPU speeds and bus speeds rose and especially as graphics cards began to incorporate 3D rasterizers.
This new language is as much fun to code in as Python without the pure-interpretive overhead. The latest Xcode includes a "playground" prototyping space that makes it easy to experiment with pure code, including library API calls, before cementing your work into the application framework of iOS or OS X. Right now it's a one-manufacturer language, and still beta, but something tells me it's going to spread.
part of my nostalgia for coding on the C64 is how you felt you could know everything about the box. There was a book, Mapping the C64 and C64C. 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 with that nostalgia.. there's an offer on that book for >700 dollars. I lost mine over the course of several moves during College days.
In the "old days" programmers just took debts by not doing the extra work. every time a few years later someone had to pay for that and most time the ones responsible for it were long gone. a quick 100 lines of code is a proof of concept, never a proper solution that can live.
I deal with dipshits like you all the time. Heck, half our dev staff spends weeks/months on rather trivial software projects and still can't even get them past the barely useable state because they want to write fun trivial applications. So, anything beyond that, is too much for them to break apart and do right. If you want to write 100 line "applications" knock yourself out. When you want to join the grow-up world, let us know and we can help you cultivate the necessary skills to be a real software engineer.
In my pocket I carry a page of quotes of computer scientists, engineers, and others on simplicity.
The two here are snippets from Dijkstra:
"the purpose of abstracting is _not_ to be vague, but to create a new semantic level in which one can be absolutely precise"
"the main challenge of computer science is how not to get lost in complexities of their own making"
That is, you always have a tool to solve today's problem, which is to increase the level of abstraction. Over time you pile up abstractions and precisions and solve many problems. And then you wonder why things have gotten so complex and get nostalgic.
You haven't done the hard work to lower the level of abstraction, or pivot it into irrelevance. Great software has a rightness that fits its domain snugly, that knows and does its job efficiently. It captures general patterns and allows the expert to navigate by intuition.
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 be maintained by anyone other than the original author.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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?
I'll say this to anyone who thinks they can't program, learn VB.Net :)
Lots think of it as a crap language, but that's what it is - an entry level language and after learning this, you can go a number of routes to more advanced languages.
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.
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.....
despite what we're told by decades of Disney and Hollywood productions, the vast, vast majority of adults spend most of their time doing what they HAVE to do in order to survive. Only a very tiny minority get to Do What They Love and Get Paid.
The rest of us learn to use the job, to support the life. Or crash and burn in confusion that Disney and Hollywood lied to us.
The lesson everyone failed to get from Fight Club is that you don't actually get out of the rat race.
The author has a point. At one time, there were development tools, which cost money, were relatively static, and which were expected to work correctly. Then there were applications, which relied on the development tools.
We now have a huge proliferation of tools, many of them open source, poorly integrated with each other, and most badly maintained. Worse, because everything has a client side and a server side, there are usually two independent tool chains involved.
Web programming is far too complex for how little most web sites do. (And the code quality is awful. Open a browser console and watch the errors scroll by.)
Perhaps the disagreement is whether it counts as "version control" to have a weekly tarball as the revision history and diffs as the change sets.
What, REP MOVSB? You can't be serious. Instruction sets were so small, you could easily keep them all in your head. There was a reference manual, and the reference manuals were really good.
Everything is specialized and we literally have no jack-of-all-trades coders anymore, pity...that's what we need IMHO.
I would consider myself one of those. I don't pretend to be the ultimate expert in anything I work with, but I've had enough exposure to enough different environments and situations to at least be competent in just about any problem domain, or say, "y'know, over on this other system, this is how we often do this and it might be a more appropriate solution to the problem at hand". It cracks me up anytime Mr. "I'm the best thing since buttered bread" can't figure out why his VM isn't working because he's got a network submask set wrong or something similar, or is completely lost when presented with a Linux command line because all he's ever worked with is Windows and the filesystem organization is totally foreign to him.
However, my experience has been that coders that specialize in one particular thing but can't do anything outside that domain are far more marketable than those with a wide breadth of general knowledge and honest about not being the do-all and end-all of any one skill.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
doctors like single player systems as they don't have to put up that much paper work and billing BS.
anything that is repeated over and over again with known rules can be programmed
The rules change for each other system with which your system has to integrate.
I had read wholeheartedly. One can no longer just dip keep their feet in the programming pool. You have to learn the IDE, frameworks, and object model abstractions, design patterns... It is so aggravating that stuff has become so complex in programming.
That one of the most successful paradigms of software development is the Unix paradigm: Simple apps that do a single thing really well. Many parts of the GNU codebase haven't been touched in years, because it works. For some reason, ever since the mid 90's when Java and other technologies were developed we have this notion that software should be developed to do everything under the sun, reinventing the wheel and introducing unnecessary complexity.
Just look at web-design. As a systems programmer who is used to doing things in C at a low level, I feel like to do something simple for a web app takes me hours longer than it would if I had coded the same functionality in C using POSIX or similar cross platform libraries.
All those frameworks and APIs not only introduce all sorts of programming complexity, but they also turn programs into memory gluttons.
It often appears that real craftsmanship (making the most efficient code for the job) is no longer valued.
I could like code so many lines per day, and I didn't have to learn all this complex stuff like SCM and IDE
now, with the new tools, I'm like a 100x more productive (and I'm makin nice GUI stuff , no command line) but I have to learn the tools... I long for the old days, when you didn't have to know how to read or write to be a horse shoer, it was so much more productive
what a whiner
I thought I was the only one. It feels like the people considered the best programmers now are the ones who know the complexities of git more than the next guy. I thought I was the only one who felt like the cycle of Jira, Git and Reviewboard was much more brutal, time consuming and complicated than the few lines of code that I'm able to squeeze out on any given day. Then, since everyone has their own way of doing just about anything, every line of code is scrutinized and disected - and often changed. I used to be a great programmer, now I can't produce the amount of Jira/Git/Reviewboard FUD that others can, and thus I'm reduced to less than average.
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!
Your argument boils down to "Engineering is hard".
Not at all. The main point of my argument is that the idea that requirements are free to be changed, regardless of scope, is resulting in implementation being far more expensive than it needs to be, and IMO this isn't a good engineering practice. How many development shops take the customer aside after a project is finished, show him the dollar amounts for all the change orders, and point out that having had the requirements more in order beforehand might have ended up only costing him only half of what it actually did? "But you saw new stuff working every two weeks, even if it wasn't what you really needed!"
Requirements analysis is (or should be) just as much part of any engineering discipline as construction. Some degree of change is inevitable, but we shouldn't be in the situation where we build an airplane with four wings before determining two would have been sufficient.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
You could work (for free...) on some suckless projects. Their projects have line of code limits to prevent over-engineering. You can easily read and understand the code of any suckless project, even if you're not an expert. Patches are really easy to write as well.
"Software development has become a mostly operational activity, rather than a creative one." And this is a bad thing?
No frameworks. No testing. Just save - refresh plus a bunch of PostgreSQL queries. I get so much more done.
Absolutely agree
Coding used to be fun. Now you write scripts (python etc) or spend a lot of money - or it gets complicated.....
I think programming is fun again, like it was in college, now that I quit doing it as a profession, and now do it as a hobby.
Uh, Linux geek since 1999.
Are the newer movies, with vastly better special effects, really better than the old .. or than a book?
No, not really. All too often they are not as good; certainly not as unique.
What we have is increasing levels of thrill and eye candy making what used to be good enough now no longer. It's not a good road we're on, on the whole, as complexity grows geometrically while functionality grows, at most, linearly .. and too often not at all.
"Modern" quickbooks or excel has little in the way of critical new functionality versus what was available ten years ago. But it has vastly more lines of code and runs no faster (especially considering how much faster processors have become).
"We have become the tools of our tools."
Generalists do better in small shops because they can't afford to hire a specialist in 10 different areas when they only have budget for 4 people.
From: http://vpri.org/fonc_wiki/inde...
---
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...
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...
---
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. :-)
---
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Yeah, I know such people, who "just want to code". Their code looks really this way: an unstructured, non-intuitive, spaghetti code full of hacks, one bit away from falling over and as slow as a snail. Regularly those kind of people writes a thousand lines of code (of this kind) where you could solve the problem with 100 easy lines.
Ever saw a mechanical engineer saying "just let me build!"? Would you trust him building your car or the plane you are going to fly with across the ocean?
Ever saw an electrical engineer saying "just let me build!"? Do you think, he could build a CPU or a mainboard you would like to use?
I think the problem is that on many projects the requirements are not known enough for a complete definition. Agile and spiral design processes work well for these designs because requirements are discovered during each cycle.
I love Jesus, except for his foreign policy.
I can't disagree that many problem domains have unavoidable complexity. But why do we fall for using tools that promise to encapsulate the complexity, but then fail to do so. ...and leave us with both a complex working environment AND a complex problem domain. Give me Notepad and 1000 small C files (or asm) any day! (Just be sensible about includes and defines...)
There are basically two things that make a job pay well: Rarity of the skill, and complexity of the task. Back in the day, computer programmers were a very obscure and rare trade. Nobody knew much about the arcane inner workings of computers, so the few people who did know something about it were able to extract a good hefty paycheck without having to do anything particularly complex. However, now there's a flood of people on the market who are reasonably well informed as to how to make a computer do what they want. 100 line C programs can be cranked out by outsourced Chinese workers for pennies on the dollar. You can probably even find a college intern to do it for free if all you want is someone to read a spec, and produce code that works. So, "simple" programming is not well paying anymore. Now, if you want a career with reasonable pay, you have to start tackling the "complex" tasks. Sure, writing thread locking is fun and all, but nobody really cares how your semaphore code is working, what they care about is whether the website properly shows your profile picture on the next screen after you upload a new one, and that their 600 friends all see the new picture in their stream too within a minute. That's not a "simple problem" so if you want good pay, that's the kind of problem that you're going to be asked to tackle.
I seem to be spending a lot more time rebasing git commits and reading/writing code reviews and doing the necessary email to merge request further-rebased git commits into the main branch than actually fixing the code.
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.
The fact that you wrote this un-ironically about Agile assures me that you have never, ever worked on a properly-run Agile project in your life. Now, it's not your fault if your managers thought "no planning" was all they had to do to have an Agile process. But I assure you that changing massive parts of initial requirements simply means that you thought Agile would solve the problem of your inability to plan or conceive a product. Agile won't do your thinking for you.
Why do you expect joy in your work? If you want "just to code" - do it on your own time. Or find another job with more "just coding." These jobs do exist, but they might not pay that well.
Puh-leeze. Come up with something more original. The "please kill yourself" thing has been used in angry AC comments for a million times already.
The problem is languages are old, and complex. C, even C++ are too old, designed decades ago, modified to adapt, but old. Even PHP, Python with its simplicity are behind of today's needs. Today's needs are a mixture of things like PHP and JS frameworks or Java and C++ and mix that with Server Administration, Cloud. In that mix itis the reality that a lot of the work is done by solving the real need (like managing a warehouse and inventory) and the rest is accounting or trying to find logic in ilogical and even stupid management fails. Programming is trying to mimick a problem and then create a solution and improve it... but we are basing everything in stupidity, things that we don't need, like you can create an amazing game concept but you need to adorn it with a good interface because otherwise you lost all the OCD potential customers. Or creating an amazing and organized form than nobody uses because it is boring or lacks JS validation because people can't stand a freaking page reload even with a high speed conection. It is a problem. Because simplicity is not part of our lifestyle anymore, we are using old solutions in a world that "evolves" in things we don't really need. That is the result. Not to be confused with real evolve or change, that will always be faster, but at least (maybe) well ordered.
http://www.quasarcr.com/
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.
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.
"But I deliver small parcels by bicycle. Not my fault that my boss read a management book written by someone in aviation, and has us go through several page checklists every time we get on a bicycle".
its a good 5 liner with both fundamental claims being false. 1. apps are complex - and business logic complexity (also called as noone ever thought it clearly over) grants a worse programmer experience than tool complexity (at least one guy thought it over - and it works in a well defined environment) 2. project overhead is not that bad - for me at least. but yeah the tools I have to use suck a bit. so whats the whole point they advertise some new IDE that will be simplish? (in its birth its missing features as it grows it will be sluggish? :P)
also why can't I frigging add a linebreak to my post ... is it a signature thing for slashdot, every post must be a wall of text without formatting?
I've been coding since about 1984. I cut my teeth in the demo-scene doing intros and the like on C64 and Amiga and eventually on PC.
I've used pretty much every tool, language and platform that has been and I've had a good opportunity to sit back and watch the industry grow/(d)evolve.
For me it's always been a hobby and my career and as another post mentioned I still manage to enjoy coding as long as I make a very clear separation between what and how I code for work and how I code for fun.
From a career perspective I've been involved in a wide array of sectors, financial, web, intranets, mobile, insurance, telecomms, game-dev, gis, tech start-ups so I've also been lucky to be exposed to a wide array of styles, practices, team and company structures etc from 1-4 man shows up to 8,000 person organizations. I'm not a youngster anymore but I'm also not an old-foggy so I think it gives me a unique perspective on the situation (I can balance my nostalgia for yesteryear with the practicality of modern tech and forward thinking).
I think one important thing to bear in mind with all of this is that there are a million wrong ways do something and only 1 (or a few) ways to do it right. As the industry evolves it needs to make mistakes, do things the wrong way. The important thing is that people need to learn from these mistakes and move forward in a positive direction. I don't see that happening that much anymore.. I'm quite happy to have a lousy system which I know is going to continually get better, but that seldom seems to be the case these days.
The industry has a number of problems as I see it currently: .. is it for desktop.. is it for web.. Get it right.. make it good and leave it well alone the damn reference books get published and before they've even hit the shelves in some places they're already obsolete! .. build a product which may have significant overlap with what another part of what google is doing, they'll usually come up with a few really great ideas in it but then cock the whole thing up by not considering it a go-to-market product so it's usually ergonomically flawed and then they drop any real support for it and it just meanders along.
1) There are far too many people re-inventing the wheel and replacing one half-arsed system with another instead of fixing or improving what is already there.
2) Every second college kid feels the need to be a web2.0 rock-star and release yet another framework or library.
3) The image of the whole industry has gone from hi-tech computer nerd to silicon valley chic which to me seems to me bringing in the wrong kind of people.
4) Organizations like MS seem to change direction far too often, back-track prior decisions and have too much developer churn. It shows in their products when they bring on a new team or try to introduce a paradigm shift, the whole house of cards comes crashing down (Windows 8, Office 2013, Visual Studio 2013..Lync..).
5) Taking C# as an example.. there should have been a point where as a language it was mature and stable. This constant need to evolve it and make it fit every case with more elements / syntactic sugar is ridiculous. Is it static is it dynamic
6) Google suffer a slightly different problem.. I shall call it perpetual-beta-forget-me-itis. People go off on a tangent
7) Documentation.. engineers can't write it... most programmers can't write it... and it seems these days most companies don't care. I think back (some nostalgia to kick in) about the sort of printed book/manuals that you used to get for things like Pascal, GW-Basic or the Amiga ROM-Kernel manuals. Absolute brilliance... We have to ask ourselves, once we used to be able to code WITHOUT relying on the Internet or StackOverflow and simply using some txt files we had, stuff from BBSes and real hard-copy books.
8) Following from 7 part of the problem is the actual documentation itself.. the other (and this is one of the key things I want to raise) is that while we've made progress in some areas, in a lot
1993:
mov ax,13
int 10h
2014:
http://msdn.microsoft.com/en-gb/library/windows/desktop/dd370994(v=vs.85).aspx
1993:
in al,60h
2014:
I won't even bore you with the details, suffice it to say it's going to cost you a lot of money, you'll need to join some SIGs, become a USB member, read 10,000 pages of specs and spend 6 months coding.
If you understand the above .. you'll know what I'm on about.
ÃoeSimplicity is the ultimate sophistication.Ã
à Leonardo da Vinci
ÃoeAny intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius Ã" and a lot of courage to move in the opposite direction.Ã
à E.F. Schumacher
Everything should be made as simple as possible, but not simpler. ~Albert Einstein
So this is a college new-hire's book report on Mythical Man Month?
Welcome to the playground, new guy.
What's wrong with VIM, GCC and BASH?
I have one 16-bit for You son: You are not a programmer.
Pick up an Arduino and start playing. It's like a return to the 70s or early 80s. A simple, clean environment. An incredibly large number of frobs. Interface libraries and code is FREELY available by the ton. And you see a problem, you piece together sensors and effectors, and you solve it. Then you give the code away.
For me, a breath of fresh air.
All the easy problems have been solved. Most of the hard ones have, too. The intractable ones are still being worked on.
There haven't been many breakthroughs in mathematics recently, either. It's all tiny incremental steps.
I would not work for a company that told me to just write code. While a lot of standards and management go overboard, it is mostly about the fact that when working in the corporate environment I have almost never reworked my own code. 95%+ of what I work on is updating someone else's code and I'd rather the time and effort learning their code be saved by them following some sort of standards.
Most companies don't even spend enough time writing requirements to define what the software should do. They often focus on the most important 5% of the design and ignore the rest, then complain that what I implemented doesn't match what they didn't tell me they wanted.
The main problem with the usage of these kind of tools is that they often is used as a remedy for the lack of skill and knowledge by the programmers.
And they of course always fails that.
Managers without managing skills in the area of IT projects = easy target for selling tools.
Mundus Vult Decipi
Perhaps you should be looking into getting a job as a research programmer. Working in academia (or at least in the vicinity of acedemia) tends to bring with it a certain degree or freedom and excitement that you might not easily find in business stuff. If a scientist has figured out some new fancy algorithm on paper it's your job to make it work. You'll still be doing what others want you to do but in an environment where you are on some kind of bleeding edge, have some freedom to experiment, don't always have to jump through all the hoops of quality assurance (because in research projects it's more about having a working prototype than about shipping a product with all the inherent legal liabilities), and even get paid for it. Granted, it's not for people who are "only" programmers but for people who know something about the relevant science in addition to knowing how to transform abstract algorithms and data structures into performant computer code. Come to think of it, at the end of the day it all boils down to this: If you want to do interesting work you need a certain level of education or at least it doesn't hurt to have a certain leval of education when looking for interesting jobs. Take home message: Look beyond programming as an end in itself.
I felt the same way. Work became work. Fortunately I got out of the rat race and no longer have need of money and I can work on the projects that I want to work on. Well, to be honest the rat race has destroyed most of my desire to code any longer and I haven't worked on anything for the past 3 months, but I'll start up again once the joys of summer and fall pass. :)
I pray God the father, the son and the Holy Spirit, Jesus, Maria, and the apostres, the Angels, so that we all have bread, love, the forgiving of our sins, and good and nice coding environments, and nice jobs, and nice friends and health or at least healthcare. Thank you very much. I no longer code on computer : it's too hard today with my mindillness. I code on paper. Greetings from France, European Union. May the peace and love be with you.
I'm asking it like it's a bad thing, because how many times I could read there that it's a cancer like flash, pdf and whatever little things. But I just checked yesterday, and it exists for Windows too. And intended for actual use, unlike something like Wine on Windows. And you can even bundle the runtime or bury it in your .exe program.
There are many "one true way" to develop things that work everywhere : java, python, web/javascript, some older things and some newer things I'm sure. But if I want to get started to do little projects, have to pick something. Web would be nice, but maybe I'll never have a smartphone to run little web apps on. My calls and positions are already tracked just by owning a dumbphone.
Back on point, one of the early posters said how he uses C#, and it would probably be a nice fallback / somewhat default language to do semi-system stuff, networking, multimedia, imperative programming.. or gasp, a GUI. What would draw me then is the F# language, and I know its parent language a bit (ML family). It would be awesome to be able to do actual useful stuff in that language (thanks to .NET libraries/infrastructure and some additions or sugar in the language) and if worst to come (i.e. something where functional programming is pointless or gets in the way) I'd use C# or whatever other language supported in the Mono CLR for those parts?
It's 2014 too and maybe Mono is better in 2014 than in 2009 or 2007.
He makes stuff that is extremely well-done, made from top-notch solid hardwoods and employs some extremely creative design.
It takes him quite a while to make one of his pieces. Each one is custom, unique, and perfect.
It costs a LOT.
His customers are almost exclusively rich folk.
He drives trucks for a living.
It's pretty difficult to make money doing high-level craftsmanship, these days.
It's also damn near impossible to have a high-level craftsmanship team.
The Japanese have figured out how to do it, and the Koreans are catching up fast.
Americans? Not so much.
The problem with the Japanese and Korean approach, is that you can get super high-quality, low-price products produced in bulk, and of incredible complexity, but the innovation tends to be diminished.
The Germans are the only ones that I know of that seem to be able to get innovative craftsman teams producing a large quantity of high-quality stuff.
However, their stuff ain't cheap. A Mercedes S-class will usually cost more than 5 Toyotas. It will probably last as long as 3 or 4. The Mercedes-Benz company is a pipsqueak, compared to Toyota.
It really comes down to scale, and economies, thereof. It's also all about "good enough." Microsoft was (at one time), the largest and most successful software company on Earth, and they ran on the "good enough" model.
Teams of code monkeys, under strict (and not fun) conditions, can produce Toyota code (or Yugo code, if you remove the oversight). Teams of craftsmen can produce Mercedes code. They can often have more fun doing so. They tend to have just as rigorous a process as the code monkets, but that process is internalized, and is an unspoken language understood by the whole team.
I pray the Good God, the Father, the Son, and the Holy Spirit, Jesus, Maria and the Apostles and the Angels to gives us food, bread, love, and to forgive our sins, and then perhaps nice coding environments, nice jobs, nice friends, and health. I no longer code on computer, it's too hard for me, with my mindillness. I code on paper. And that gives me immense satisfaction.
First of all, let me say up front: I'm not a professional programmer, just a hobbyist. I could understand the need for complicated tools when you're part of a large-scale operation or programming for a corporation. But the author's not talking about that at all.
On private projects, I keep hearing myself spit out between expletives, "I just want to code."
Why don't you? I write little programs all the time, in Tcl/Tk, in Javascript, in C++, in Python. I don't use an IDE. I don't use any version control though I probably should. (I'm starting to learn about Git and Github.) My bug tracker is a bunch of comments at the top of the source file, or if I'm feeling ambitious, a separate text file called "NOTES".
But what I don't do, for the most part, is share my programs with anyone else. If I were planning to release something to the public, I would have to spend a lot more time figuring out all the dependencies of my software, putting in more robust error checking, writing documentation, submitting the program to an App Store or at least putting it up on Github, etc etcyeah, that would be a drag. But I don't know that any of that is necessary; it's just important if I want other people to find my software to be useful. If all you're interested in is the problem-solving puzzle aspect of programming, or in writing something to make *your* life a little easier, then there's no need to follow the herd. Do what the heck you want; all the old tools are still there.
Good people are losing jobs these days because of hubris. I got into development for two reasons: 1 necessity, 2 i liked it. Unfortunately, because I'm self taught and don't hold a degree in CS or IS, and can't grasp every framework de jour, I'm slowly again being push out of a job (career). Sad. I have good skills, but can't compete with Joe programmer who's been doing this stuff since he was 14. What makes it worse, management is getting on board with the "technology for technology's sake" crowd, resulting in bloatware, complexity, and less stability/ more complex maintainability. And for what purpose? Apparently, it's mostly to stroke egos and secure jobs.
The fact that you wrote this un-ironically about Agile assures me that you have never, ever worked on a properly-run Agile project in your life. Now, it's not your fault if your managers thought "no planning" was all they had to do to have an Agile process.
And he probably hasn't. But that's ok because about 90% of people who are claiming to "do Agile" aren't doing it properly at all and are, in fact, just paying lip service to the notion of "agile" and simply storming ahead with the "no planning" ethic that you suggest that they are.
If you're one of those people who genuinely has worked on a "proper" agile project then you are very much in minority.
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?"), but it almost never works all the way. Another reason is that the situation changes, whether by reorganization or new laws. I've also seen requirements people meet with the managers of the workers who are going to use the project, but that's simply bad requirements analysis. I've also been on a very successful scrum project where our hardware engineer was still doing basic design work while we were getting the preparations done. We did know the overall system very well, and so we had a good idea where we were going to have to make changes. I wouldn't recommend that process for everything, but it saved time getting a new process ready for customers.
Doing visible accounting of the cost of change requests is useful, and on a large project you really do want a change control board. You usually have to be prepared for large changes anyway.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
My sentiments, exactly: just LET ME CODE!
And even with all of that, you can go back a year later and look at your code and think, "Wow. I have learned a lot since then. I should recode this section."
âoeIn theory, theory and practice are the same. In practice, they are not." â Albert Einstein
I get the impression the author have not coded very much if he still is struggling to fit together features such as multi language and data storage in new projects.
The business "grew up" and became managed. Lots of time and energy is spent on the process rather that the product. It seems that Apple is or was one of the few companies that spent more time on design, than process. It's not that the cabnit makers are all gone. It's that they are all being managed by "productivity" managers. Jobs said his company was the largest company run entrepreneurial style. Everyone reported to him. Look at the tools. Apple used for years one language: Objective C. That is the C language with objects. The guy who invented it just wanted to add objects to C. That is a whole different approach than specifying a new language or using C++ or having a committee decide on what language they would use.
I work at a local college, and we also have to have meetings, our work is monitored, we have several HR videos we have to watch each year, etc. I earned my teaching certificate 35 years ago. I think I know how to teach a basic English composition class by now. At least I don't have to have parent/teacher conferences.
http://programming-motherfucke...
How/Why? Complexity: Especially DCOM vs. WebServices - DCOM, imo @ least, is a nightmare by comparison to doing websites with real functionality for users (yes, DCOM works, but working with it is FAR more complex than putting up a Script Driven DB accessing website, for example). Security considerations aside @ least & yes, BOTH DCOM + The Web, of course as we ALL KNOW on the latter especially, have them!
Imo @ least, yes - that's WHY web-driven programming "took off" the way it did. More coders could easily grasp & utilize it.
APK
P.S.=> Good post man - I wouldn't have put it *QUITE* the way you did, but your point's solid enough... apk
Ah yes, the battle cry of the agile apologist. "If it didn't work, you are doing it wrong"
Any one size fits all process is a failure.
Confusion between consultant and contractor? Many consultants say what needs to be done but do not implement their suggestions.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling