Businessweek "Code" article 6/11/15

steelyman

Moderator Emeritus
Joined
Feb 13, 2011
Messages
5,807
Location
NC Triangle
Businessweek "Code" article 6/11/15

I think there are a few "coders" around here?

The June 11, 2015 issue of Bloomberg Businessweek has a feature article "What IS code?" that may be of interest. It's online at present ( www.businessweek.com ), but an interview about it sounded interesting enough to me to try to find a printed copy at several stores (wow, that's not easy these days!).

There isn't a specific quote I can use as is the preference at e-r.org, but it's a general-purpose article to help people understand a bit about what "coding" means.
 
Last edited:
Good article and explains many of the uncertain issues surrounding the many diffrent languages of code and how it gives upper management fits because the coders can't give black and white answers to questions like; how long will it take or how much will it cost to write or modify a certain code. The article is a bit long winded but an interesting read nonetheless if you want to know a little about the nuts and guts of coding and the people who do it.
 
It's also an interesting glimpse into the mindset that has overtaken coding and the culture that resulted.
 
Good article, yes it drug on much like the endless nonsense that advanced technology is.

Imagine giving a contract to build a bridge to an organization that had little planned, in fact the plan was to figure it out as we go along. They may refactor the bridge (tear down and build again) as they go. Don't worry you'll get a chance to try it out all the time! Would you award them the contract?
 
LOL, I use to program, I quit before scrum became mainstream. If people only knew how many bugs everything has in it.. engineers talk all the time about how so many things could go wrong...so wrong. You can see that women do not make up a large percentage of the population and that they tend to drop out as time goes.. I think that has a lot to do with just how disorganized it all is, the in-fighting.. you can only sit through so many meetings of people arguing non stop about whats the 'best' language and not getting anything actually done. Its a lot of egos.. all trying to prove who is the best, often writing code which is so complicated no one can actually read it, decode it, or fix it...that person deems himself "winner" as now he is the only one who can fix it, thus making him irreplaceable.
 
... Its a lot of egos.. all trying to prove who is the best, often writing code which is so complicated no one can actually read it, decode it, or fix it...that person deems himself "winner" as now he is the only one who can fix it, thus making him irreplaceable.

I used to tell my team - "If you write code that no one else can maintain, you WILL be replaced".

Although it was painful in many ways, our semi-formal code reviews were a very good thing. No way was the team going to approve some code that was a nightmare to try to understand/maintain, knowing they might be the ones that are called upon to maintain it. And since we supported 24/7 production, that call could literally be a 3AM call.

-ERD50
 
Thanks for the link, ERD50. Amusing.

My programming is limited to EXCEL these days, and not much of that.

By the way, I remember a Robert Heinlein novel that anticipated a glue language like Python. Can't remember much other than that.

Imagine giving a contract to build a bridge to an organization that had little planned, in fact the plan was to figure it out as we go along. They may refactor the bridge (tear down and build again) as they go. Don't worry you'll get a chance to try it out all the time! Would you award them the contract?
For all the classes in engineering economy there are, it is surprising that none of that wisdom floats up into management. I find many, many projects that were simply pulled out of someone's *ss and run down the field without critical review owing to managerial genius. These things happen in boardrooms all the time.
 
I used to tell my team - "If you write code that no one else can maintain, you WILL be replaced".

Although it was painful in many ways, our semi-formal code reviews were a very good thing. No way was the team going to approve some code that was a nightmare to try to understand/maintain, knowing they might be the ones that are called upon to maintain it. And since we supported 24/7 production, that call could literally be a 3AM call.

-ERD50
I am impressed! Good on ya.:clap:
 
I've done my fair share of coding in the early days (machine code, assembly, FORTRAN, Forth, various versions of Basic finishing with Visual Basic). I read the first third of the online version of this article and I thought it was a terrible description of how computers work.
 
When I was in school, the department had populated a lab with various types of computers, mostly PC-style computers but also a good representation of Apple/Mac offerings. Off to one side was a bank of these exotic workstations made by Sun Microsystems. Sun's ongoing marketing message was "The network is the computer". I think that was right back then and has become even more true as computing and networking evolves.
 
Interesting article. Much has changed since my college days in computer science in the late '70s. Although I had a 30+ year career in IT, I only "coded" for the first four years before moving into management, and the last half of it was primarily around managing infrastructure rather than applications. I keep thinking I should try out CodeAcademy or one of the other online learning programs to learn one of the newer languages, but it hasn't gotten to the top of my list yet.
 
... I keep thinking I should try out CodeAcademy or one of the other online learning programs to learn one of the newer languages, but it hasn't gotten to the top of my list yet.

I tried it for a while, it was pretty good I thought. But as soon as I got past the first few lessons, and had to start getting very specific about syntax (do I need a "," there, or a ";", etc), I just found it tedious and dropped it, since I didn't have any specific project to do, and no other motivation like putting food on the table.

-ERD50
 
I've done my fair share of coding in the early days (machine code, assembly, FORTRAN, Forth, various versions of Basic finishing with Visual Basic). I read the first third of the online version of this article and I thought it was a terrible description of how computers work.
Ah, a true computer guy! Always having a criticism first. You'd fit right in where I w*rk.

I'm not really busting on you. it is the way we think.

I felt the same too, but after standing back and looking at the audience, I thought this was a pretty good overview and window into my w*rk life as explained to those on the outside.
 
LOL, I use to program, I quit before scrum became mainstream. If people only knew how many bugs everything has in it.. engineers talk all the time about how so many things could go wrong...so wrong. You can see that women do not make up a large percentage of the population and that they tend to drop out as time goes.. I think that has a lot to do with just how disorganized it all is, the in-fighting.. you can only sit through so many meetings of people arguing non stop about whats the 'best' language and not getting anything actually done. Its a lot of egos.. all trying to prove who is the best, often writing code which is so complicated no one can actually read it, decode it, or fix it...that person deems himself "winner" as now he is the only one who can fix it, thus making him irreplaceable.
He addresses this issue in the article.

In my mind, it is a very serious issue. It would be a benefit to see more women in the field. My perception after 30 years is that the percentage is actually going DOWN.

I will also say that new world cultures have come into the fold of software engineering, and these cultures bring with them very strong Alpha-Male type of behaviors, many times bordering on misogynistic. You are right about the ego, but it goes beyond. Sometimes they just babble to babble. It "looks good" to constantly challenge and criticize.

This is one reason I'm glad to be in the OMY world right now. I see the end and can't wait to get there.
 
I may have to suggest this article to my scrum. Not kidding. I am an older version of TMitTB, without the blazer and ninja socks.

There's lots good in this article, and there are some flaws, but so what. It gives the outside world an idea of how we computer guys work these days. (And I say "guys" to emphasize karen1972's unfortunate point.)

The biggest flaw I see in the article is a lack of explanation of "Cloud" and how that works. You've probably all heard about it, even if by absorption from various TV commercials. I could probably write a full article myself about it, but suffice it to say it adds yet another layer of complexity and techno-babble words on top of the simple "coding". Cloud allows the programmers to buy "free" computers and add them to a system. It is incredibly intoxicating. Where before you had to work in the constraints of a small computer, you now have what appears to be unlimited resources. You simply add more computers to the solution. They are "free" after all.

It is hard to explain, but suffice it to say that Cloud will be giving management even further headaches in the future when it comes to techno-babble.
 
As a non coder I found the article very interesting and have a new appreciation for websites, email, etc. It did drag on a little long but found it found it very informative overall.
 
Back
Top Bottom