Learning (needlessly) hard technology(johndcook.com) |
Learning (needlessly) hard technology(johndcook.com) |
Not being free to pick alternatives is a common case. There are a lot of dev teams out there that have "approved technology lists". What gets on this list is decided by management and/or a lead architect. It can often be the case that simpler alternatives can't get used because they aren't approved.
This isn't necessarily a bad thing. I could see project management saying "no" to simpler solutions in the name of preserving the stability of a project. Besides, a sufficiently talented team should be able to work within such resource constraints and come up with creative solutions anyways.
Another third situation that I would agree with: Clients sometimes really do not like to trust new technology.An age old anecdote is always brought ; "Why fix what is working?"
I assume you know it really is possible, right? (in URL parameters - with certain limitations about size if I remember correctly... or did just IE choke at 2048 bytes? I forget...) I am not arguing you should use GET instead of what should clearly be a POST, but saying it is not possible is IMHO misleading. And there are sometimes valid business reasons to use (invalid) technical solutions.
I understand your point, but neither extreme (always staying with legacy / always rebuilding) is particularly good.
The are good career reasons to think long and hard before specializing in this stuff. After all, once you go too far down the rabbit hole, you may not be able to climb back out, and nobody wants to be a 35-year-old developer with a completely obsolete skill set.
But if you're a 55-year-old consultant, you may be planning to retire long before the systems you're working on disappear. In this case, I can't see anything wrong with specializing in ugly, valuable dinosaurs that nobody else wants to get near. Under the right circumstances, I've heard of this work paying $350/hour and up.
Exactly
Also you spent time learning something completely unusable beyond a certain niche, that usually does not transport anywhere back to "sanity land"
I'm strongly opposed learning something that will be good for nothing beyond actually making the wheels of bureaucracy and/or legacy turn
The concept is called lock-in. One can build a career strategy on it if done right. Just ask all the people working 9a-5p getting paid a premium to do SAP, legacy Microsoft, Oracle, COBOL on IBM mainframes, pipelines between legacy data sources/consumers, and so on. Some of this gets hit by outsourcing but many jobs remain. And one can always start an outsourcing consultancy with in-country, priority support or services. ;)
So, it's a valid approach that's working out for many much better than alternatives which require dozens of constantly changing skills and high layoff risks due to being replaceable & easy to automate. I'm not saying it's the best or lowest risk approach. You'll probably hate the career unless you see work as a means to an end to have fun in spare time. It's got lots of potential though.
I suspect that a good majority of corporate code assets trend toward becoming unnecessarily complex. After a certain level of complexity is reached, a company will often look for that better alternative and decide to rewrite from scratch. But in many/most cases of this that I know of, this attempt to recreate/rebuild is found to be intractable.
What seems to happen is that more and more developers are hired to maintain the complexity and I wonder if that's what most developers out there are doing, maintaining complexity, which always makes me think the same thing:
>> That sounds like an unpleasant way to earn a living.
Oh they are. No need to wonder.
I don't sell myself as a PDF expert, but my level of knowledge and experience is high enough that I can maintain and improve systems and workflows tightly bound to them. I keep it on my resume, but have no desire to mine that resource for fear of being the canary.
There's a nontrivial amount of technologies that are complex and otherwise byzantine for no reason. Given the lack of alternatives, knowing the arcane tech inside and out can provide for a sustained stream of money, but that's hardly ethical.
Back the 1990s, GNU autoconf looked like a miracle to me, and in fact, back then you got better results compiling from source than you got using what passed for a package manager.
These days people complain that autoconf is too complicated, being a bunch of shell scripts on top of shell scripts compiled with M4.
Then there is SAP, which stands alone in its ability to destroy value. SAP started out as a mainframe application, got ported to Unix in the 1990s (not many succeeded at that) and now they want you to run it on an in memory database for which you can't afford the hardware, never mind the software.
Anyway, I can hardly think of a dumber way to spend my oh-so-valuable time then to spend it on learning a tech just because its "needlessly" hard (yes I know I'm overusing the parenthetical, for effect of course), but to each their own.
To be honest, learning it as a strategy to bump up one's rates could be considered a rather smart thing to do, but of course you had better understand the true economics of the move and know thy markets.
Aren't most of us interested in making (more) money?
It would be nice to know of what he is speaking of.
Trying to be everything to everyone is one of the surest ways I know to generate byzantine monstrosities. On the other hand, it takes some real nerve and discipline to tell 'No, that is not really what our product is about' to a paying customer.
It takes good engineering, and you still won't be able to say yes for every request (for lack of time if no other reason), but it does not require your product to be needlessly hard to use.
It's also not for every product. I just wanted to point that exceptions exist.
The main school of thought in business these days is still organizational and process focused. Only the newer guys think of business in terms of products, SOAs, SDGs and APIs, and it'll take decades yet for that kind of thinking to fully infect corporate America.
It gets unwieldy if you try to build complex data structures, because you literally have to do everything the compiler would usually do. So if you're trying to build an incredibly complex machine with lots of objects and interfaces, it will take you a very long time.
Java is complicated because the culture is complicated. It's not just a language - it's a set of architectural practices and expectations, some of which are questionable, combined with a unfeasibly large ecosystem of libraries and add-ons.
So it's easy to learn the basics, but it's not so easy to get to the point where you can start producing high-quality maintainable code within a typical working context.
Assembler is simple like lego is simple: the basics are tremendously easy to understand but the distance between the basic elements and the problems you're trying to solve is very large.
The more 'batteries included' something is the more time you'll spend learning about the eco-system and less about the language per-se.
To summarize: You do not need to always rebuild or always stay with legacy code.You need to adapt and determine where would you spend more of your development effort.I cannot spend 80% of my time solving problems that the world has already solved
[1]:http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-send
Edit: Of course this isn't recommended, but I think the time wasted trying to convince the (seemingly terrible) manager could have been better spent.
[0] http://www.boutell.com/newfaq/misc/urllength.html
Because that would be an easy place to send data.
I don't think that's a fair assessment of Java. The full specification for version 8 is actually 788 pages, so 500 more than C, but you could reasonably argue that of those at least 100 are dedicated to specify what in C is simply undefined behavior and probably another 100 are dedicated to the memory model. The other 300 hundred would be a reasonable overhead for specifying classes and class loading.
You can say a lot of bad things about Java, but it could very well be the best specified language around; the spec is actually very readable, leaves no room for doubt and actually treats that thing called multithreading that still has no citizenship in the C language. You can't say that of a lot of languages.
EDIT:
I took the time of checking the C11 standard PDF (actually the latest available draft, as the ISO asserts copyright on the standard and you can't get it for free). It's 701 pages. But at least C11 has <threads.h>.
The C standard library was a relatively small affair reflective of the way UNIX was built, a couple of well thought out interfaces combined with a lot of freedom (and enough rope to hang yourself several times over).
The Java standard library was absolutely huge and extremely hard to make headway in because each and every part of it seemed to be designed by a committee rather than by an individual (or two).
The x86 set, well, let's not go there, it's just too painful.
And assembly is simple as in 'primitive'. The atoms of assembler are instructions, and even they may be clustered into only a few groups i.e. arithmetic, branch.
I find the resistance to learning assembler is mostly fear. When debugging I very often resort to assembler display, even for machines that I'm not familiar with. I can learn the gist of it in a few minutes just by looking at a little generated code. And there's nothing like the actual machine instructions to find what really caused an exception.
Not necessary. As a young programmer who did not grow up in the java dominated world of 1990-2008.
I took one look at Java and noped the fuck out.
I found C to be more useful.
But its hard to beat the simplicity of java-script.
I disliked java after school and was convinced I was hopeless so I didn't even bother to apply for Java jobs. Then I was recruited into a Java position and picked up the necessary skills to work during my first 4 days and improved steadily from there, but it only worked for me because I was on a good team.
Now it is me who helps people using Java more efficiently : )