• Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Is programming getting easier

suityou01

Potty-trained
Thanks received
222
Linky

Another factor is the changing nature of software development. In the last few decades, and especially in the last five years or so, we’ve seen a raft of products introduced that make programming more of a “gluing parts together” than ever thought possible. This doesn’t mean that, in the future, there won’t be programmers, but it does mean that there will be a pretty deep split between the people doing the “gluing” (who will be about equal to a factory worker from the early 1900s) and the people designing the glue and the parts.

What do the panel think? Are you happy doing the gluing, until your job is no longer there or do you become a manufacturer of the parts?

How would you makes this shift in your field? Is this a wake up call, in that we should all be thinking about simplistic plan bs that would help us differentiate ourselves from being a gluer?

The boy simonmac was doing his web site the other day, most commendable, but is it enough?

Thoughts?
 
been done to death.

After seeing lots of companies who can't even order parts from regular suppliers or build stock items on time let alone get paid the same numpties building scalable enterprise software with pick & code tools leaves me thinking its all going to end in tears and kerching for contractors.
 
There's different levels of gluing expertise. Selecting the right bits and gluing them together in a way that is maintainable, robust and extendable is still a skill that many lack.

A bit like cooking - give me and Norrahe the same ingredients and I'll throw together something edible whilst she creates a masterpiece.

I think the problem is that companies no longer want the masterpiece if something edible is cheaper and fulfils the satiate hunger requirement.
 
There are so few people who have a clue that those who do will be fine. Perpetually at their wits end due to being constantly amazed by the stupidity of others, but apart from that, fine.
 
There's different levels of gluing expertise. Selecting the right bits and gluing them together in a way that is maintainable, robust and extendable is still a skill that many lack.
.

This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.
 
It can be the case of glueing things together STL, Boost, MFC etc. However, understanding what needs to be glued where takes someone with skill.

Understanding what to do when glueing things together does not solve the problem takes even more skill!
 
This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I agree but it's not enough. IMO developing applications and systems, including 'processes' that will be used by humans requires empathy. Too many organisations have automated all sorts of processes, connected all sorts of applications and then de-skilled customer service, and customers end up in a Kafkan trap, having to try and find their way through opaque procedures while not being able to talk to a person with the expertise to help them. Telecoms and government are particularly bad in this, but many other companies fail here; a developer with empathy will build an application that serves the needs of the customer or user, and reassures the user that his problems will be dealt with. A designer/architect with empathy can ensure that a system is clear to the end user, and that there aren't ways of getting trapped between two departments, or that your data is incorrect in thousands of databases and can't be corrected. IT people might do well to read Kafka's 'The Trial' or read up on Habermas's Lifeworld/Systemworld distinction. Strangely, I come across more and more testers who take an interest in literature and philosophy, particularly testers from the Context Driven Approach. There ARE developers who do this, but I think they're rare; maybe they are just too pressured to learn the latest tool instead of broadening their intellectual development.

The Dutch national ombudsman touched on these issues in an essay that's worth reading. He's talking about how government deals with people, but it could just as well appy to many large organisations.
http://www.nationaleombudsman.nl/si..._management_and_fairness_-_engels_artikel.pdf
 
Last edited: 12:03
Linky



What do the panel think? Are you happy doing the gluing, until your job is no longer there or do you become a manufacturer of the parts?

How would you makes this shift in your field? Is this a wake up call, in that we should all be thinking about simplistic plan bs that would help us differentiate ourselves from being a gluer?

The boy simonmac was doing his web site the other day, most commendable, but is it enough?

Thoughts?

It was always gluing bits together, the abstraction level just get raised each time there an "advance" in programming language design. It used to be functions, then modules then objects then components then services etc......
 
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I once worked as an embedded softie on a system for a high profile passenger aircraft, and had to peer review a package of code this guy had written to get 3 DSP's talking to each other over two channels. (Imagine a triangle ABC with two channels between each node). But if any comms channel between two DSP's went down, message still needed to be routed via the 'other' DSP. (So it had to act as piggie in the middle).

It was going through his code (all done in C, from 'first principles') I realised:

(a) Software Development is also an art; there is a certain beauty to see in code that is finished, working, maintainable and efficient. No different from a mechanical machine like a watch or a differential.
(b) I was never going to be a brilliant Softie. So I've settled on being a mediocre one. :)
 
This comes back to my point on the big data thread that many(most?) programmers are simply hackers.
Creating software that is "maintainable, robust and extendable" requires training, experience and a certain (artistic?) flair that gives a programmer an eye for "elegance".
Very few programmers have this latter quality and most on here will wonder WTF I'm talking about.

I did some analysis a few years back. It turns about 10% of developers fall into the category of non-hacker. I recall they were in quite different myers-briggs categories (for what they are worth) than the hackers.
 

Advertisers

Back
Top