September 23, 2011 at 6:17 am
<rant> As long as when you "anticipate" future requirements, the code is not bloated if they never come, that's fine. I've seen too much overuse of design patterns anticipating requirements that never come and the code is over complicated, less maintainable, more prone to bugs, etc, as a result. If you have one class that does something, you don't need a factory pattern just because you "anticipate" more similar class may be needed in the future. If those classes are ever needed, it's easy enough to create an interface and switch statement at that time; 5 minutes extra work that would have to be done either way, so why do it up front if there is a chance you won't need it? KISS </rant>
September 23, 2011 at 6:25 am
I've seen three elements, none necessarily technical and quite interrelated:
Critical thinking skills - the ability to verify information received, understand it's implications, and question the assumptions upon which the information is based should be a skill taught and reinforced from an early age throughout life. It's the antidote to the old saw about ass_u_me.
Basic logic - If A and B but not C, then. . . To me, a firm grasp of logic parsing at both the conceptual design and detailed implementation stages are critical for success. Building a program, database, or complete system without a solid foundation of how logic works at this abstract layer is doomed to some level of failure.
Cause and effect - what are the possible causes for the event in question, whether its a unexpected change in a column value, or a major outage, determining the (true) cause is a increasingly rare skill. Paraphrasing Holmes, when you eliminate the impossible and the improbable, what remains must be the cause. Determining the impossible is easy, however, evaluating the likelihood of the improbable and whether it could have caused the event in question seems to be a significant challenge to many.
September 23, 2011 at 6:41 am
I would put communication skills at the top of my list.
Know your audience and communicate accordingly.
Instant communication is not necessarily good communication. Because you can text/i.m./tweet someone instantly doesn't mean you should. It encourages lack of thought.
Please think before you write.
September 23, 2011 at 7:02 am
For me, it must be lack of proper design.
A program, database, network all need a proper design.
Whatever happened to "back to the drawing board", and I mean a real drawing board.
We try to solve problems in meeting rooms, yet nobody present any design that shows the big picture and then we wonder why things go wrong and take so long to fix.
September 23, 2011 at 7:04 am
One of the basics I've seen lacking in some data professionals is the use of stored procedures. I'm amazed by the number of developers I've come across, who have been programming for years but still prefer to embed SQL in their code rather than writing stored procedures.
September 23, 2011 at 7:10 am
paul s-306273 (9/23/2011)
What caught my eye was that Miguel de Icaza talks of reading books on the bus - glad it's not just me who uses the bus...
Letting someone else fight the traffic for you day in and day out can give you extra time each day. I have thought about giving up the daily drive for a number of reasons.
Besides COBOL, Fortran, Pl/1, ASM, C#, VB, SQL, and now Ruby I ccould use the time for even more languages such as Japanese, Russian, French, Spanish, Portugese (I know folks in Brazil) and even a refresher in English. Hmm. Do those "stone" people have a course in Esperanto?
ATBCharles Kincaid
September 23, 2011 at 7:31 am
I confront the "Universal Hammer" syndrome. "If all you have is a hammer everything looks like a nail." Much as I love it not everything is a SQL statement.
People bemoaned the fact that early SQL did not have procedural asspects so along cam triggers and stored procedures, now the CLR. I'm not complaining about all the cool stuff in SQL server. There is stuff in here that I have not gotten to, yet. Rather it is the mindset that "SQL can do everything so we don't need anything else". The pressure to add more stuff into a thing is constant.
ATBCharles Kincaid
September 23, 2011 at 7:37 am
I've been in and out of IT for over 30 years. I have a degree in Computer Science and an MBA in Finance. I was a master mainframe COBOL programmer in 1977, managed programmers and technicians over the years.
What I find lacking in the IT world is an understanding of the underlying principles.
I've never used Oracle, but I could pick it up and muddle my way through it the same way I've muddled my way through C# and VB and a dozen other languages. It's not because they're similar to COBOL, or that COBOL was similar to FORTRAN. It's because, as an undergraduate assignment, I wrote a compiler for ALGOL (in ALGOL.) It forced me to understand how compilers work.
I also wrote a loader in some assembler language I'd never used before. Later, when I needed to write a few utilities in IBM 370 Assembler, I muddled through. Took awhile, but I muddled through and succeeded.
My family sometimes marvels that I can open up Facebook for the first time (or some other system...) and "muddle through" to success. It's because I understand how programmers think and try the right things.
I will have to admit that returning to programming after being out of coding for 25 years was difficult, but I made it through and bring value to my clients over and above what they pay me. It's because I look deeper than just "how do I do that" to "what's the best way to do that", and "is that the right thing to do..."
Education, as opposed to professional training, is sorely lacking in our industry.
Jim
September 23, 2011 at 7:52 am
I would tend to agree with Ben.
The IT generalist mindset is missing. You don't have to know how to write assembly language on any computer, but knowing how tends to increases your understanding of how any application truly works.
I was talking with a young, non-entry level developer about some of their code and was explaining why it was working the way it did rather than the way he wanted it to -- he had no clue how the processor really worked. Snazzy IDE and the mechanics of programming are no substitution for basic knowledge. It really shocked me that the depth of knowledge was so superficial.
And although I tend to think of myself as a software guy -- the hardware matters too.
September 23, 2011 at 8:23 am
Well said!
September 23, 2011 at 9:10 am
majorbloodnock (9/23/2011)
I've been doing a lot of nodding whilst reading some of these replies.For me, the following are major gaps I see, often in surprisingly senior IT people.
...
Excellent list of skills.
September 23, 2011 at 9:18 am
BenWard (9/23/2011)
If you understand what the server is ACTUALLY doing you can anticipate such problems and think about it before you run it.People seem to forget that every tool, every utility, every api, every object and even things like the SQL engine itself is actually a program that was written and compiled by a human.
I think the problem is more that we build such high level functions that aren't optimized for scale, but for small work. When we combine them into larger items, it doesn't work well.
It's like a builder building a wall. he knows he mixes sand, cement and plasticiser and uses it to stick bricks to eachother, but he may have no idea where the bricks come from or how sand is ground down or why the cement makes it go hard.
I think it's more like giving people assemblies of bricks that are already 3ft x 3 ft and having them try to figure out how to build a 5ft square chimney, or a 30 ft square building. Those larger building blocks might not scale well.
I believe IT pros should, as a matter of course, do stuff through the command line from time to time. why? because when RDP goes down and your clicky interface doesn't work, you can fix it without having to reboot a live server. Write a little program in C every now and then, even though a powershell script would be easier to write. why? to keep yourself in touch with what your machines are actually doing for you.
thats my rant over 😉
This is why I think everyone should have to do C that writes code. Not that sysadmins necessarily need to, but devs/DBAs do. I think it teaches you care and lower level skills, as well as respect for what the machine has to do. I would say that we should give them a VM w/ 1MB of RAM and have them solve problems for 6 months, just to learn how things work at a lower level.
September 23, 2011 at 9:47 am
Steve Jones - SSC Editor (9/23/2011)
This is why I think everyone should have to do C that writes code. Not that sysadmins necessarily need to, but devs/DBAs do. I think it teaches you care and lower level skills, as well as respect for what the machine has to do. I would say that we should give them a VM w/ 1MB of RAM and have them solve problems for 6 months, just to learn how things work at a lower level.
That's an excellent idea. I was thinking of hosting a 6monthly development competition at work. Give developers a task to do with specific requirements. For example, one such competition our TA took part in some years ago was to write a program to convert every instance of the ascii character x to y in text files in a folder as fast as possible. He did it in assembly language but lost the competition to a guy who did it in C, the guy who did it in C cached chunks of files in RAM whilst our TA was running straight from disk.
This sort of thing encourages developers to stop and think about the most efficient ways to do things, and provides a great learning experience, with the incentive of winning a bottle of wine or whatever. The competitors had no idea when he started the program that there were going to be 11500 flat files to process, this taught them to 'plan for the unplanned'.
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
September 23, 2011 at 12:06 pm
When I started off the most junior position was analyst/programmer. This meant we had to sit infront of people who would eventually use our product. that was nearly 30 years ago!
The nature of the complexity of our tasks meant that we had to do quite a bit of design upfront in order to be able to build what was required. It wasn't "big design upfront" but it was designing things first. Quite often this would flush out problem areas and contradictions early.
These days it is all minimal if any design, give the customer only what they have had the wit to ask for, let them paint themselves into a corner then tell them that this is the "cost" of agile development and that a fundamental tennant is to accept that todays delivery may be completely invalidated by tomorrows requirement. It's a bit like selling endowment policies without warning that the investment might not pay out!
We also had to have quite a broad spectrum of skills from wiring a plug, soldering, installing and configuring cards through to UI design. I think that programming has now become a much narrower job rather than a broad vocation. I empathise with Phil Factor's article Two shops short of Dagenham[/url]. I really miss the oddballs we used to get in IT.
One character found out that the boss was using a dating agency. "Light drinker, non-smoker, middle-of-the-road politics! No wonder he needs a dating agency"!
September 23, 2011 at 1:29 pm
I'm moving from doing 30 years of VMS/COBOL programming into the world of Windows. Mostly working on SQL Server and Report Builder right now. I want to eventually broaden out for that, but first want to get good at those and SSIS.
Just wondering what suggestions people have for self-training. Also ideas on what pitfalls to avoid.
BTW, many of the comments on this topic so far pertain to any type of IT world.
The one thing I don't think I've seen stated directly, but has been implied in many comments, is that it's just as (or more) important for IT folks to learn about the business as it is to learn the particular languages or tools they will be using.
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply