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?
...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.
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.
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.
It sucks, but I'm intentionally throwing more of my time now into learning the latest languages and development environments. Are they better? Not really. But you will never, ever convince anybody that fuddy-duddy is actually cool. They'll just think you're irrelevant. Every career has some drawbacks, and spending your life chasing fads, coupled with others' disdain for everything you did or learned over a decade ago, is a drawback of this one. (Heck, why didn't you start a successful startup or at least move into management by now, anyways?)
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.
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.
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?
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.