Slashdot Mirror
Getting Back To Coding
New submitter rrconan writes I always feel like I'm getting old because of the constant need to learn a new tools to do the same job. At the end of projects, I get the impression that nothing changes — there are no real benefits to the new tools, and the only result is a lot of time wasted learning them instead of doing the work. We discussed this last week with Andrew Binstock's "Just Let Me Code" article, and now he's written a follow-up about reducing tool complexity and focusing on writing code. He says, "Tool vendors have several misperceptions that stand in the way. The first is a long-standing issue, which is 'featuritis': the tendency to create the perception of greater value in upgrades by adding rarely needed features. ... The second misperception is that many tool vendors view the user experience they offer as already pretty darn good. Compared with tools we had 10 years ago or more, UIs have indeed improved significantly. But they have not improved as fast as complexity has increased. And in that gap lies the problem.' Now I understand that what I thought of as "getting old" was really "getting smart."
Write code.
I have an issue with my programmers when they know how to use the tool, but don't understand what they created. I overheard one group discussing a new system, and the one stated she didn't know where the code actually ran. No one in the group did. The Integrated Development Environment hid the details. No wonder people leave gaping security holes in systems if they don't understand how they work. I have really smart people who don't understand how the application server accesses the database. They just write code, and it works. They get used to figuring out how the tool works, not how the system works. If the tool is replaced, they are lost. If required, I'll go fix it in a text editor, because I understand what it's doing. I don't need an IDE to tell me. I know what information is flowing through the system, and how it does it. That way I can prevent inappropriate data from being exposed to outside users. IDE's are very useful to speed development, but you can't base your entire knowledge of programming on how to use a tool.
Sounds like we need some Programming, Motherfucker!
Do you speak it?
FTFA "The reason that so many tools have become unwieldy is that they chase after certain values that add complexity but not usefulness to SMB-sized projects"
If the author of the article would just choose his tools more carefully he could have saved himself these weird rants about things that he brings on himself. It's like a bike rider lamenting how uncomfortable his racing bike seat is when he's riding it around the block.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
...Everyone says "I only need 10% of what this word processor will do." Everyone else will agree with that statement. The problem? The 10% I need is not the 10% YOU need.
I find the article strangely short-sighted. Sure, we have to avoid overengineering solutions that are not going to be needed in the near future. But to say "you should not code features that are not immediately needed in the current sprint" will lead, in most cases, to significant rework in the future. Rework is money and time.
A key part of the work of a smart project lead, whether that lead is an active developer or not, is to anticipate the product direction. The lead has to be able to say, "Sure, we're only going to write this subset of functionality *now*, but it is a near certainty that users will want this expansion of it in just a couple of years. We might as well have the basic framework for that in place, even it's only stubs."
Further, our tools are complex because our needs are complex, even at the SMB level. I've been a developer for 30 years now, writing everything from experimental personal-use stuff, to local utilities, to enterprise software that is used by some of the largest manufacturers on the planet. Even small users expect unanticipated cases to work. Big customers expect that, not only do unanticipated cases work, but that migrations to new versions will be tailored to THEIR needs and will happen without notable incident. As but one small example that means that internal testing of a new release not only has to work as a brand new install, but it must also work as an upgrade, and it must work as an upgrade against the specific data and specific customizations (real software is customizable), even when you don't know what those are. If you expect success in that environment, you're going to need a LOT of tools: source code management (to identify what changed when you introduce a regression), an automated testing framework, a way to test builds and build functionality, a framework for testing upgrades against real customer data (that they let you use for this purpose), and then tools and processes that let you track code reviews, approvals, and the like. That's a lot of tools, and a lot of staff to follow it all around.
My organization has some excellent tools, and developers assigned solely to maintain them for the rest of the development staff. It means, though, that any new developer coming in is going to have to learn a lot more than a programming language.
...on how to best create software. It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on. There is simply not enough money being invested into making better programming tools. The fact that free, open source software is so pervasive in for-profit companies is proof of that. Everyone would rather take what they can get, squeeze as much money as they can out of it in the near term, and wait around to benefit from everyone elses investments back into the technology.
I'm in systems engineering/administration, so the vast majority of my "coding" experience is focused on automation and scripting. Predictably, stuff like this is very procedural and different from application development. However, the biggest shift I've seen is not really in the complexity of tools, but the shift in focus to gluing together pre-defined parts. Sure, languages have always had standard libraries, but development (especially in the mobile OS or web framework environments) often leaves me trying to figure out how much I would have to code from scratch and how much work has been done for me simply by including Massive Functional Library X. Don't get me wrong, it's a good thing to not have to do everything yourself, but I sometimes wonder how much control one gives up when they just write an app by putting someone else's code together.
One example from my side of the fence is Windows PowerShell. It's amazing, but it really requires a complete shift in thinking if you're used to writing VBScript. JavaScript or batch language automation. With the other languages, you have to write lots of code to parse command output or iterate through a WMI structure. Some of the stuff is so complex that sysadmins who don't really know the under-the-hood workings just cargo cult the whole thing and make a mess. PowerShell became useful to me when I realized I no longer had to write chunks of code solely dedicated to reading the contents of formatted CSV files. Lots of the complexity of that rolls up into a line or two of script. Again, it's not a bad thing, but if you're used to DIY, it makes you wonder how the "magic" is being done. When you move up the stack (iOS, Android, etc.) that abstraction is even more stark...as in, just call this library which handles the entire database-access layer that used to be huge amounts of coding.
c/c++, vi/emacs, make, ddd.
Lots of good years of use, likely many more years of usefulness, too.
Uh, Linux geek since 1999.
No criticism of the OP here, but this got me thinking about one of my mortal enemies. The UI within SQL Server Management Studio. For the last decade of upgrades, I've really wondered how that development team leaves the office everyday thinking they are doing a good day's work. There are so many blatantly apparent rough edges to the UI for SSMS, I can't believe they think it's as good as they can make it.
In order to avoid tldr, I'll just give a single example. Look at the tabbing for each database connection window. The tabs are labelled "servername.database" but are limited to a small number of characters regardless of how many tabs are open. Here's an example where there are only two open tabs:
http://img.informer.com/screen...
The first reason the labelling is fundamentally broken is that the database name is chopped off in an unnecessary abbreviation. The tab could stretch out to display the whole thing! It's not scrunched in with a bunch of other tabs. There's plenty of room there.
The second reason this is broken is that the database name is the thing you actually need to see more than the server name. In the majority of use case scenarios, the user is connected to multiple databases on the same server. When switching tabs, you need to be able to locate the one for the database you're looking for within your current connections. Sure, there's that pulldown menu on the left, but that's a much further mouse drag than the tabs are from your focal point.
So, if you're ever looking for an example of a developer interface that doesn't get a proper update, look no further than SQL Server Management Studio. It's hardly changed in over a decade of releases.
$5 / month hosted VPS on linux = awesome!
This advice is what I give people who ask me "how can I learn to program computers like you?"
Build something. Find a problem and solve it. It doesn't matter what the problem is or how you solve it.
Write a tic tac toe engine, or a photo slideshow generator, or a fart joke generator, or whatever you want to do. But you just have to do it.
As a (mostly) hobby programmer I agree. Tool complexity is much too high. Programming languages and widgets toolkits are relatively fine, though (except for intentionally blown up languages like Java). The real problem are the tools for building, packaging and deployment. For example, I was considering to package a cross-platform application I wrote for the Ubuntu "app store" but gave up after studying the in my point of view fairly complicated rules and process. Kudos to all package and repository maintainers, it seems to take more time packaging an application than actually coding it. I also admire anyone who masters the complete GNU toolchain, which, again, seems to require more programming in incomplete domain-specific languages with arcane syntax than writing the program to be built.
I wish I had more time. Busy people like me need tools that allow them to write an application, copy&paste the docs and icon images and produce the executables for all major platforms. Some commercial toolkits come close to that, but unfortunately even those that once have started as affordable shareware have become ridiculously expensive.
However, I'm not convinced that the reason for that state of the art is featuritis. Having the features never hurts, it's the way the tools have to be configured. Too many authors of programming tools do not know or do not seem to care much about ease of usability.
Not just programming tools have usability deficiencies, though. I'm afraid GNU/Linux, which I use daily for work and fun, has similar problems. For example, Ubuntu frequently bothers me with a dialog asking me whether I want to give "an application" access the default key chain without telling me which one. How could you decide whether an application should be allowed to access your passwords when you don't even know which one? This is not only insecure, it makes no sense at all.
Yeah, well, enough whining for today ... it's not that bad, is it ;)
New languages. New frameworks. New IDEs. New magic procedures...
Some of it is good, surely. Who programs without classes these days? But every time I see someone come up with a magic new net language, framework, etc., I sort of cringe. I mean, do we really need another one? Do we need all the ones we have (I'm lookin' at you, Ruby...).
The elephant in the room here that Microsoft, et. al. seems happy to ignore is that it takes time to learn AND recode this stuff. Time is money. If you're a teen or a student, you have time to mess with the next Ruby, or Dart, or GO, or BrainFuck or...
As a kid, you have no money invested, and plenty of time. There's no risk.
Fast forward 25 years. You still code for a living. You have a house, a wife, kid(s), car(s). You and your spouse are paying for all of this. Suddenly, genius boy at Microsoft invents Powershell! and convinces a few PHBs to roll it out. Suddenly, all your clients want Powershell! Quite frankly, you haven't got the time or interest in learning Powershell!. You wanted .net features added to VBScript and/or Jscript. You wanted backwards compatibility with existing VBscript and Jscript code. You wanted something that added value, not something that subtracted value by forcing you to go back to the drawing board and recode perfectly functional tools to satisfy a corporate IT security requirement from the corporate PHB that says, "Use Powershell!" for which you may, or not be paid, depending on how well your contract was written.
Disclaimer: I like Powershell, but it was the wrong decision.
The problem, quite simply, is this: Change!=Improvement. Change!=Better. Sometimes you get lucky. At other times, not so much.
Please do not read this sig. Thank you.
Yep, I live in the stone ages, but at least I know every corner of my systems.
What this world is coming to - is for you and me to decide.
I don't really understand what you're trying to say here. I don't know COBOL. Are you saying that if you gave me an assignment to parse a data stream in COBOL, and I couldn't do it in COBOL because I don't know COBOL, but I could both demonstrate a solution in another language and learn COBOL at a later date, I would still FAIL?
A good rule of thumb is that you must understand your program at least one layer of abstraction past the user layer to be truly competent with it.
That's frameworks, libraries, languages, whatever.
This knowledge is often the difference between the experts and the experienced novices, and I think we all innately know this once we've experienced it. Java provides a nice example, because they build that requirement into their certification program and learn about obscured concepts like memory utilization and object creation, but examples exist elsewhere. That 'Aha!' moment when you read Effective C++, or when you grok EF, or understand why Backbone.js does the things it does in the way it does them. I've even seen it on graphic designers who were forced to write raw HTML and CSS, rather than Dreamweaver or Muse.
This isn't even a program-from-bare-metal argument, it's just simply a matter of understanding the underpinnings in order to write decent code, instead of just adequate code.
Sorry Petey, but the coward was very clear. He doesn't like IDEs for GUI editors normally, but the only place (android) where he thinks it would be useful, the options suck.
It wasn't actually a hard one to understand.
And he has a point, because XML is designed to be human readable in the loosest sense, but it is not designed to be actually written by humans. And CLI tools are very awkward on android, because most android devices don't have a physical keyboard. If you're knowledgeable enough to be commenting on this story, you should know all that already.
There hasn't been anything new in CS since the 80s.
No really.
Nothiing.
AJAX was new. Used to be the terminal and back-end would only exchange data when you hit the xmit key, and of course the web re-invented this pattern adding nothing new, but then it actually went a step beyond. Of course, it's mostly abused in horrible ways to punish the user for the crime of being a customer, but then, what tool isn't?
Other than that, yup, mostly re-inventing of the wheel by people young enough not to be there for the last trip round.
Socialism: a lie told by totalitarians and believed by fools.
It seems really, really tough to get anyone finance-minded in the *business* of making software to understand that it's worthwhile to do exploratory development of tools and techniques to be much more productive later on.
Perhaps, but any such exploration and the resulting tools have to beat the baseline of a decent text editor, a decent version control system, a decent scripting language, and starting to write code within a minute of deciding the project is ready to begin.
For a long-running project with many developers and other contributors performing repetitive or error-prone tasks, maybe it will be worth investigating, selecting and adopting some external tools to automate some of that work, at some stage in the project when you know where the pain points are. But if your development team aren't newbies, they will be perfectly capable of building their code manually at first, they will surely already know their universal Big Three tools very well, and importantly, they will just code up any basic automation on the fly as the project grows and the needs become apparent.
IME, that turns out to be a surprisingly tough standard to beat. I've seen many, many projects get bogged down in their own infrastructure because they felt they should use some type of tool and forced themselves to do it, not because they necessarily needed that tool or found it useful in practice. Of course good tools can be useful, and of course sometimes it is better to bring in help from outside the project rather than being too NIH about everything, but it's important to stay focussed on the goal and not to forget that tools are only means to an end.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That's all you need. (OK, implicit with c is the c compiler, pre-processor, assembler, linker, disassembler and strace). The old timers knew what they were doing.
Stick Men
Are you kidding? Efficient design peaked somewhere in 2000. Today, they're too simplistic, too spartan, and waste too much real estate, and then try to cover it up by sticking search boxes all over everything. The gap is only apparent because methods to complex processes have since been dumbed down for the benefit of illiterate users at the expense of making it as quick as possible for users who do know what they're doing to get at what is needed. This has made them harder to use for all but the simplest tasks.
I reached that point in the 90's.
Now I write all my code in a meta language that compiles down into COBOL, C, C++, C#, Erlang, FORTH, Fortran, Google's Go, Haskel, Java, Javascript, Perl, PHP, Python, Ruby, Rust, and more.
It takes about two weeks for me to learn a new language and write the "runtime" for my meta compiler. Then I can deploy all of my existing solutions on the new platform faster than the other guys can get "Hello DB Connection" out the door.
Fuck all the shitty languages and "new" platforms. Now that you've actually grown up and stopped being a fucking fanboy, go write your own meta compiler. I'll open source mine when I retire, it's what gives me the edge over all the noobs still wasting time reimplementing their wheels.
Here's news for you mate. There is no shortage of skilled workers. There is only capitalistic elites applying very strict selection requirements via flavor of the month bullshit requirements (ignoring that coders learn new languages without having to get a degree or cert). This is done so they can pretend to be looking for workers, when in fact they are trying NOT to hire anyone so they can meet the government's requirements and employ more lower paid H1B visa workers. There are actually HR seminars about how NOT to hire people while still complying with the requirements of looking for work. "Oh my, you don't have a Certificate or Degree in $LANG, I'm afraid that's a requirement. Yes, you may say you know it, but how do I know that?" In fact, they just filter all applicants by their strict filter and you don't even get interviewed. They have to interview a few folks, just to seem legit, but that's the nature of this beast.
http://www.washingtonpost.com/...
Not the same guy but I think we are on the right wavelength.
Here. Now go parse that stream using Cobol.
I dont care if you have ever heard of Cobol or not. I have never used it myself, and I havent been a working programmer in decades. But if I needed a parser written in Cobol I expect I could search for the docs first thing in the morning, find a syntax reference, and have a working if rough parser done before lunch. If this sort of work was needed by me on a regular basis I expect I would become very familiar with Cobol and a week later I would re-implement that parser in less than an hour and do a much better job.
All a computer can do is math, or if you prefer to think of it as symbolic logic, fine. But it's still all the same stuff. Any high level language you use, no matter how strange the syntax, no matter how unfamiliar the vocabulary, is still the exact same thing at core. Logic. Arithmetic. Algorithms.
A particular language may be a pleasure to work with, or it may be a pain but end of the day if you understand logic you should be able to translate your logic into any language for which you can find useful reference documentation.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
You know what was so nice about Borland's Turbo Pascal when it came out? It was being able to write, compile, and run programs without restarting applications.
Consider my first C compiler for my home computer. I had to bring up an editor and write the code. Then I got out of the editor and ran the compiler and then the linker, and then I had an executable. Then I got Turbo Pascal, and I could work on programs without invoking multiple applications and switching disks. Yay! I'm a lot less impressed with IDEs when I can have multiple xterms and, for example, just keep vim up all the time.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
How much time do you waste with boilerplate crap like this because of nearly clumsy array-handling ideas that date back to the Great Flood?
How bloated is code because of the vacuousness of most common languages that
require
several lines
to do
the simplest
things?
With Erlang. You will learn something that is worthwhile and will last (it's been around for 30 years).
http://learnyousomeerlang.com/content
Offtopic a bit maybe, but the big problem of the larger "word processors" is that they try to supply half of a full desktop publishing system as well and it's not the useful half. You can spam pictures all over a page but can't place them precisely - you have to fuck about with other settings and hope they wobble into place.
IMHO it's the feature creep where the word processors approach DTP without getting there that gives that 90% that is marginally useful.
Similarly with IDE's that try to approach LabView but never get there - mainly because somebody points out that a LabView GUI is almost limited to a write-only approach for small and well organised bits of code and an unreadable spaghetti explosion beyond a certain size and complexity.
Q:How do tool smiths earn a reputation? Q:How do consultants retire from coding? The answer my friends is obvious, build more tools which are also more complicated and require constant throwing away of previous tools and work. Git is fine and interesting but has not solved the most important problem which is merging. And neither has the VSS, SVN, or VCS or anything else I am aware of. I haven't used a build tool yet that doesn't solve the dependency inconsistencies or merge issues that crop up. Code review tools are nice to have but only address the impact of changes in a very narrow area, usually only in the area where someone is looking which is often just a few lines of code.
Test automation is OK, but amounts to nothing more that regression testing. I have seen very few negative tests even though pumping noise into a program is easy to do.
I get this uneasy feeling now and then that we are focused on shiny things ("Oh look! it uses [funny animal | cartoon character ] as a mascot!"] and not looking at the fundamental, and sometimes hard, problems which if solved, or at least tamed a little, would really help.
putting the 'B' in LGBTQ+
It's right on!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
15 years I coded with Qt professionally and came to love and adore it's quality and simplicity. I even wrote and operating system which was a microkernel and everything else was based on Qt Core.
I wanted to make a simple project the other day and Qt failed me. It seems that code goes in without unit tests these days and shipments are made without any quality control.
I used Qt because I'm not the typical loser Linux developer who wants to spend 50% of their time just fixing their tools or reporting bugs to package maintainers.
This is done so they can pretend to be looking for workers, when in fact they are trying NOT to hire anyone so they can meet the government's requirements and employ more lower paid H1B visa workers. There are actually HR seminars about how NOT to hire people while still complying with the requirements of looking for work.
http://www.youtube.com/watch?v...
Attention zealots and haters: 00100 00100
I was with him until he said use Subversion if it does what you need. I can't agree with that. Cheap forking is so superior that you have to learn it at some point.
In a word its all about 'marketing'. The sales shivs cant sell you a new copy if they haven't got some new gizmo to flog. In my experience new code / versions often get as much worse as they get better, and so often a complete rewrite leaves you with a vastly inferior product. (That's how they created Windows Vista and Windows 8...) I wish the old saying nothing ever changes were true - it does change, it gets worse.. :D
Talking about excessive complexity. My loathing for modern dev tools and OS hit a head when the cutting edge app that I was creating - (that needed a custom memory manager) turned out to be impossible to create because I just could not get enough power over the OS. The next iteration switched to looking at Linux, better but still no joy. Then I looked at crafting a custom OS, this naturally was a nightmare, but then I hit the basic wall that there's no public documentation for a lot of the hardware and that everything needs to be done through custom device drivers - which require a standard OS. The next level was to look at embedded systems - these are much better and offer real control, but nowhere near enough processing power. The final solution was Verilog and FPGA, not so bad as there were always sub-units in this app that really needed custom hardware anyway. The punch line though is that it sets a timeline for completion that could be creeping up to ten years, a lot more costs, and...
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..
Compared with tools we had 10 years ago or more, UIs have indeed improved significantly.
I don't know what crappy tools you've been using, bub, but the Visual Studio UI is roughly the same as it was 10 years ago (and no complaints).
: )
Uh, Linux geek since 1999.