Software developers

Seventhson · 2012-09-03T12:09:28+00:00

Ok so as you know I am teaching myself to code c# I have a few questions. 1I heard from other people the best way to learn it is actually doing it as a jo...

Software developers

Seventhson

deefstes wrote:
Daniel Stuart wrote:Will this become a legendary thread ?
I don't know, let me just go check again who started it... Hmm yes, looks like we might be in for the long haul ?

Hahaha. But thanks for taking the time.

Just something I have come to realize is that I need to get into this game. I know I can do it. And this time I won't get scared off.

Gearhead

If the main motivator is money, learn to design rather than code. What tends to go wrong in software manufacturing is that the design is neglected and the coding tries to make up for this. You wouldn't want to live in a house that was thought up by the bricklayer, would you?
Read "Design Patterns" by Gamma and his GoF, follow up on some more modern comments and interpretations and then decide for yourself if you want to lay bricks or make drawings...

deefstes

Gearhead wrote: If the main motivator is money, learn to design rather than code. What tends to go wrong in software manufacturing is that the design is neglected and the coding tries to make up for this. You wouldn't want to live in a house that was thought up by the bricklayer, would you?
Read "Design Patterns" by Gamma and his GoF, follow up on some more modern comments and interpretations and then decide for yourself if you want to lay bricks or make drawings...

I'm not sure what exactly you refer to by "design". The fact that you mention "design patterns" suggest that you're referring to the architecture of software engineering. I would agree that it is important but I would resist the notion of "learn to design rather than code". No software architect becomes one without haveing extensive knowledge and experience in coding.

Yes, being versed in different software design patterns is an important concept and integral part of software engineering but by no means the starting point for someone like Daniel. It is a fairly advanced topic and not something I think one should concern yourself with until you are really involved in the full life cycle of projects. Someone in Daniel's shoes would probably first become proficient in coding, from where he'd be able to join a small team of coders where someone else would be responsible for the project architecture and design patterns. From there, he'd be able to gain experience in the broader aspect of planning a project and developing it to certain design patterns.

If you're referring to graphical design, I'd have to disagree with you more strongly. For one, I don't think the main motivator should be money but even if it was, I think you'd find it hard arguing that graphic designers make more money than software engineers. Like I say though, I don't believe money should be the main motivator anyway and it is way more important that Daniel finds something that he enjoys and with which he has a natural aptitude.

Seventhson

My natural aptitude would be music ?
But today I really enjoyed what I did.

Also I have a bit of knowledge with blend.

Gearhead

I was referring to architecture and software, and although I agree that some coding knowledge is vital to proper design, I do think that most people start off learning a coding language while implicitly taking design decisions that make no sense and therefore produce unprofessional software.
If you're interested in programming as a hobby, sure, leave it. It's just that I wouldn't want to spend time learning to code while you could be... Playing guitar! Unless there was a financial reason.
My suggestion was to read and then decide. Not to study into depth and then forget all about c#. It's just that I think bricklayers who can understand the importance of a house being built to drawing, make better bricklayers. I also tend to think that not many architects are actually very efficient bricklayers.

Bob-Dubery

Gearhead wrote: I was referring to architecture and software, and although I agree that some coding knowledge is vital to proper design, I do think that most people start off learning a coding language while implicitly taking design decisions that make no sense and therefore produce unprofessional software.

'zactly.

There's different levels of design in programming. Unless you're coding from a detailed flowchart you will have to make decisions about how you're going to handle some piece of the puzzle. Do I do this in a loop? How do I control that loop? Do I need to write a function/subroutine here? Etc etc (this, incidentally, is the level of design that the book Code Complete deals with). Ideally the code will be easily read and understood, be robust, be extensible.

I can't tell you many times I've ploughed through some piece of overlong code written by somebody who may understand some business process or other, and knows the key words and syntax of the programming language involved BUT knows zip about programming. You're confronted with multiple layers of nesting (that, apart from anything else, drive the code past the edge of the editor window); redundant code all over the place because they just kept on repeating something instead of moving the code into a single routine and making calls to that; torturous, multi-level if..then..else constructs because they don't understand boolean logic and thus can't simplify the tests and the cases. Etc etc etc. Now you want to change some calculation or other, but it's repeated multiple times so you have to find all instances of the calculation (and don't for a minute imagine that they code it the same way every time, name variables consistently and all those nice things), move everything into a subroutine or function or whatever the particular language uses and put in calls to that. And you still haven't even made the change you're supposed to be making!

So there's always design decisions to be made - unless you're an old-fashioned coder (and I don't mean that in a disparaging way) who was handed a flow chart and would just implement that in code - and the situation I'm describing above comes from design decisions made by people who fundamentally do not know how to program properly.

Which is why I suggested certain fundamentals to Daniel earlier on. Understand those and apply them and you'll write better, more robust code.

deefstes

Guys, I think you're confusing two different issues here. The concept of Design Patterns, as authored by the so-called "Gang of Four" is a very particular field of software engineering and one which is not half as important as some would have you believe. It has its place and it certainly helps in achieving efficient solutions but it has received its fair share of criticism as well and I personally am not a very big proponent of it, but that is somewhat besides the point right now.

Of course I am all for efficient and elegant coding practices - but that is not what Design Patterns are about. You get good programmers and you get bad programmers. Bad programmers are the kind which Bob describes in his last post. Good programmers will make efficient and correct use of loops, proper commenting, proper indentation, necessary but not superfluous abstraction etc. All of that can be done without adhering to any specific Design Pattern though, even without knowledge of the different Design Patterns.

For one, Design Patterns fall very firmly in the purlieu of Object Oriented Programming. Believe it or not but there are still plenty of non OOP implementations being rolled out today. Any programmer who studies OOP without having knowledge and experience of more conventional Procedural Programming will be doing himself a huge disservice. Any programmer who studies Design Patterns without having knowledge and experience of OOP is wasting his time. That's why I'm saying, Design Patterns may be useful and it may help in speeding up development time but it is an advanced topic and it would be ridiculous for someone like Daniel to read up on it when he's only getting to grips with the do-while loop or the if statement.

Or maybe I should throw it back to you this way; Say Daniel has an assignment: "Read a player's name and choice of weapon from the console, ensuring that both are valid. Then print a welcome message to the player."

Now you tell me, which Design Pattern is the correct one to use in this scenario? Is it Abstract Factory or is it Singleton? Is it Bridge or is it Facade? Is it Chain of Responsibility, Mediator, Memento or Template Method? Even more complex assignments than the one above might not be meaningfully described by any of the Design Patterns.

So, like I said earlier, it starts with learning to program. Once you've been on a team and you've gradually eased into the design of entire systems, you will need to start getting to grips with Design Patterns. It's pointless to confuse yourself with them now while you're getting to learn the basics of programming. Of course you should strive to write elegant and efficient code, but that is something very different from adhering to the Gang of Four's Design Patterns.

Bob-Dubery

deefstes wrote: Guys, I think you're confusing two different issues here. The concept of Design Patterns, as authored by the so-called "Gang of Four" is a very particular field of software engineering and one which is not half as important as some would have you believe. It has its place and it certainly helps in achieving efficient solutions but it has received its fair share of criticism as well and I personally am not a very big proponent of it, but that is somewhat besides the point right now.

Well I have no confusion at all! I wasn't talking about "Design Patterns" because until about 5 minutes ago I'd never heard of it/them. ? I'm talking about the mental activity of programming - there are design decisions to be made whilst one is engaged in that activity. Unless, as I pointed out, you do it the way it used to be done where "coders" would just code what they were told do (by a flow-chart prepared by somebody else further up the food chain) without having to make those kind of decisions.

aja

Remember, there is also embedded application programming, as for electronics. Just be aware that there is more than website and database coding.

The embedded sector is alive and well in SA and the work is extremely rewarding in terms of seeing your creations manipulate hardware, not just a browser window...

deefstes

aja wrote: Remember, there is also embedded application programming, as for electronics. Just be aware that there is more than website and database coding.

The embedded sector is alive and well in SA and the work is extremely rewarding in terms of seeing your creations manipulate hardware, not just a browser window...

Amen! And embedded programmers are very sought after. I daresay that a competent embedded programmer will never struggle to find a good job. As a matter of interest, embedded programming is one example where OOP will not help you much. Newer technologies have made it possible for programmers to start using OOP languages for embedded programming but by and large the majority of devices out there still function on good old ANSI C.

Another sector that is taking off in a big way right now is mobile software development - as in Android, iOS or Windows Mobile. These operating systems are advanced enough that it doesn't really qualify as embedded programming. I reckon we're going to see a massive boom in the mobile development sector in the next decade or so.

Bob-Dubery

aja wrote: Remember, there is also embedded application programming, as for electronics. Just be aware that there is more than website and database coding.

Absoloodely. Banks are big employers of IT staff, and not just for on-line banking apps running in web browsers. A lot of programming is still done in, as Deefstes points out, procedural languages and for business purposes. Boring old stuff like stock control and accounting. Lots of that around. Point of sale systems too... Vehicle hire.

Whether or not any of this is sexy depends on your idea of "sexy". I once had to do modifications to a stock system so that the cost of stock was calculated on a sort of FIFO basis. That was fun.

IceCreamMan

previous generation mothers wanted their kids to grow up to be doctors, my generation mothers wanted their kids to become computer programmers.... i mucked about with cobol and C ..... did not enjoy it too much...i am a curious introvert it seems. Could of made a lot of money leading up to y2k if i had continued iwth it but left coding to pursue other carreer prospects.

coding is all about logic and thinking logically .... the commands for various languages can be learnt , but thinking logically cannot be learnt,,,it has to be inherent.

good luck 7th son an awesome to see you back here

Bob-Dubery

IceCreamMan wrote: coding is all about logic and thinking logically .... the commands for various languages can be learnt , but thinking logically cannot be learnt,,,it has to be inherent.

Hmmm.... I'm not sure if it's nurture or nature. I've read essays that suggest that program is essentially a linguistic skill. That doesn't sound right to me, but a widely used language, PERL, was written by a linguist.

The logic thing... a few posts back I made some observations about poorly trained programmers who generate massively complex structures. Point is that there are tools and methods that you can learn to simply all this stuff, even if it doesn't come naturally to you.

I have reduced massive, nested IF...THEN... ELSE... structures by drawing up truth tables, combining cases where the result was the same, looking for redundancies in the new table, then sometimes applying some boolean stuff like de Morgan's theorems to simplify further (this is what us old school programmers call "boole shit" hahahahaha ... oh.... sorry).

So two things...
1) Even if you don't think you're a naturally logical type, you could still learn these methods.
2) Most of us can't hold these sort of things in our heads and resolve them in our heads. We might think we can, but we can't really.

Seventhson

deefstes wrote:
aja wrote: Remember, there is also embedded application programming, as for electronics. Just be aware that there is more than website and database coding.

The embedded sector is alive and well in SA and the work is extremely rewarding in terms of seeing your creations manipulate hardware, not just a browser window...
Amen! And embedded programmers are very sought after. I daresay that a competent embedded programmer will never struggle to find a good job. As a matter of interest, embedded programming is one example where OOP will not help you much. Newer technologies have made it possible for programmers to start using OOP languages for embedded programming but by and large the majority of devices out there still function on good old ANSI C.

Another sector that is taking off in a big way right now is mobile software development - as in Android, iOS or Windows Mobile. These operating systems are advanced enough that it doesn't really qualify as embedded programming. I reckon we're going to see a massive boom in the mobile development sector in the next decade or so.

Absolutely its a huge huge market. Phones are the thing to have and people love apps.

@Icecream man. Thanks dude ? Its good to be back. And yes I am very logical. The only thing that scares me a bit is remembering it all :-[

deefstes

I agree with Bob, I'm pretty sure logic can be learnt. I suppose you'd have to have a naturally logical mind but it certainly can be enhanced a great deal with time and practice. I know for a fact that I approach a new project with much better logic now than I did 20 years ago.

Another important arrow in the programmer's quiver is to be able to think in the abstract, rather than the concrete or specific. This is something that I think comes less natural and can take longer to refine. It is important for a programmer to be able to cut away all the specific details until he gets to only an abstract concept which can then be used to satisfy any set of similar specific details to the original. This is where I think the really good programmers are separated from the average programmers.

Seventhson

deefstes wrote: I agree with Bob, I'm pretty sure logic can be learnt. I suppose you'd have to have a naturally logical mind but it certainly can be enhanced a great deal with time and practice. I know for a fact that I approach a new project with much better logic now than I did 20 years ago.

Another important arrow in the programmer's quiver is to be able to think in the abstract, rather than the concrete or specific. This is something that I think comes less natural and can take longer to refine. It is important for a programmer to be able to cut away all the specific details until he gets to only an abstract concept which can then be used to satisfy any set of similar specific details to the original. This is where I think the really good programmers are separated from the average programmers.

Thats some good points. I must not worry and just chill about it. I can do this ?

deefstes

Daniel Stuart wrote: Thats some good points. I must not worry and just chill about it. I can do this ?

Yeah, I hope we're not scaring the crap out of you with all this talk of Design Patterns, abstraction, boolean logic and whatnots. Just continue doing what you're doing and try to follow some sort of a syllabus. EZ's suggestion of www.codeacademy.com is a great one.

And how are you getting on with that challenge? Do you need more tips or are you good? ?

RobbieZ

First, I did a lot of development of control software for chemical plants. As you might imagine, there is very little room for error ?, so here is my 5c worth.

I think there are a lot of good points mentioned by the guys. First I have to say I agree with Gearhead, design is critical. However, if you want to do it for the money, find something else ???. Together with that is to understand what the client’s needs are. Not what he wants, because that is two different things. This means that you need to learn to ask the right questions. This only comes with experience and a lot of knowledge on the particular field you need to write a program.

Getting to know how to code? That is easy. You need to read and read and read and… When I started off with a new language, I first read the basic user’s manual. There it will tell you how to use the compiler and basic structure of the language. Then I took the reference manual and read that. At that point I knew what was available to me in the language. Then I started writing code. Ensure that all your code is documented, that way you can go back and see where you could have done things better. After a few programs, you start to build the experience you need and the efficiency of your code will increase.

Here is the bad news. Nothing takes the place of experience. And there is only one way to gain experience. No different from guitar playing ?.

Good luck. I had a lot of fun writing programs and I guess I have been reasonably successful because the plants I automated is still running. ?arty:

Seventhson

I will start later. Just been busy cleaning the house joy ?
But yeah its a bit scary for a novice ?

RobbieZ No no thats not bad news. I am a hands on sort of guy. I prefer learning by doing as such.

RobbieZ

Daniel Stuart wrote: RobbieZ No no thats not bad news. I am a hands on sort of guy. I prefer learning by doing as such.

Then I am sure you will enjoy it. I still mis it, but allas, I had to make a carrer desition.