A logical approach to writing software
(This one is mainly aimed at the experienced programmers - I'm a hardware tech really)
I get the impression that a lot of the beginners posting on here are struggling
in their approach to solving some of their assignments/homework/problems.
I don't think they are taking a logical approach to the problems.
What advice would you give to them (imagine you are giving them On The Job practical training)
I get the impression that a lot of the beginners posting on here are struggling
in their approach to solving some of their assignments/homework/problems.
I don't think they are taking a logical approach to the problems.
What advice would you give to them (imagine you are giving them On The Job practical training)
This is a common problem, actually. I think it stems from the idea that a programmer can just sit down at his PC and type away and solve the problem --as if playing a video game or playing with blocks.
I usually advise people to turn the computer off, pull out some construction paper and crayons (with at least three different colors :-) and draw the problem and solution.
People generally think of the computer as a tool to solve problems, but in the case of the programmer it is the other way around. The programmer must first solve the problem in his own head, and only then can he tell the computer how to solve it. Technology is so advanced these days that people forget that computers are dumber than amoebas.
This is the same for any other trade, such as designing hardware, woodworking, landscaping, building houses, cars, etc. But for some strange reason computers make people think wonky.
Alas. :-P
I usually advise people to turn the computer off, pull out some construction paper and crayons (with at least three different colors :-) and draw the problem and solution.
People generally think of the computer as a tool to solve problems, but in the case of the programmer it is the other way around. The programmer must first solve the problem in his own head, and only then can he tell the computer how to solve it. Technology is so advanced these days that people forget that computers are dumber than amoebas.
This is the same for any other trade, such as designing hardware, woodworking, landscaping, building houses, cars, etc. But for some strange reason computers make people think wonky.
Alas. :-P
I agree with Duoas here.
For me, when I get given a new project I try to understand it as a series of logical steps, like a flow-diagram. If I do X, then do Y, then do Z I will end up with A. Kinda like making a pizza.
Only once I understand the logical steps will I begin to start writing some code. Even at this point I work in agile, my first task usually involves setting up empty functions/classes and putting a basic structure in place. This will validate if my solution is going to work. Finally I will start filling in the contents of the functions and then the data starts to flow through the application.
So even when you begin writing the software you need to do it in steps. But first you must understand your problem, and your proposed solution.
For me, when I get given a new project I try to understand it as a series of logical steps, like a flow-diagram. If I do X, then do Y, then do Z I will end up with A. Kinda like making a pizza.
Only once I understand the logical steps will I begin to start writing some code. Even at this point I work in agile, my first task usually involves setting up empty functions/classes and putting a basic structure in place. This will validate if my solution is going to work. Finally I will start filling in the contents of the functions and then the data starts to flow through the application.
So even when you begin writing the software you need to do it in steps. But first you must understand your problem, and your proposed solution.
Yes, I agree completely with whats been said, and working with OO it is even more important to get the design and/or code structure sorted out first.
@Duoas
I use pencils, I find little flakes break off the crayons and make a mess on my paper :)
@Duoas
I use pencils, I find little flakes break off the crayons and make a mess on my paper :)
I would also agree - the 'trick' (if it can be described as such) is to be able to visualise the whole problem as a set of smaller (related) problems. This can form the hih level overview, then you just repeat on each of the sub-problems until you are down to tasks you can easily manage.
Of course, it's not quite that simple in reality, but time spent understanding the project as a whole pays off in time saved not having to redesign / rework code later.
PS: It's a whiteboard for me, easier to rub out and change things:-)
Of course, it's not quite that simple in reality, but time spent understanding the project as a whole pays off in time saved not having to redesign / rework code later.
PS: It's a whiteboard for me, easier to rub out and change things:-)
Last edited on
closed account (z05DSL3A)
Prior Planning and Preparation Prevents P*** Poor Performance.
I have a large whiteboard (also known as a markerboard, dry-erase board, ouiji board, dry-wipe board or a pen-board) and a pad of paper, coloured dry-wipe pens and a digital camera, scanner and Microsoft OneNote.
I write up the 'big picture' on the 'big board', This keeps me focused on what I am doing. As my understanding of the problem and solution increases I refine the big picture. The digital camera is used to keep a permanent record of the big board (you sometimes need to wipe the board to neaten it up).
Do your research on the unknown and keep good notes (including where the information came from). e.g. If you need to use SVG file format but know nothing about it, find out first it may have a large effect on the design of the solution.
Use Use Case analysis, Mind Mapping and other techniques to get your ideas down on paper.
Design and document your data structures.
I have a large whiteboard (also known as a markerboard, dry-erase board, ouiji board, dry-wipe board or a pen-board) and a pad of paper, coloured dry-wipe pens and a digital camera, scanner and Microsoft OneNote.
I write up the 'big picture' on the 'big board', This keeps me focused on what I am doing. As my understanding of the problem and solution increases I refine the big picture. The digital camera is used to keep a permanent record of the big board (you sometimes need to wipe the board to neaten it up).
Do your research on the unknown and keep good notes (including where the information came from). e.g. If you need to use SVG file format but know nothing about it, find out first it may have a large effect on the design of the solution.
Use Use Case analysis, Mind Mapping and other techniques to get your ideas down on paper.
Design and document your data structures.
Last edited on
well we all seem to be coming from the same place, I certainly agree with everything said.
I especially agree with Duoas with the turning off computer part - computers I think stifle creativity.
I especially agree with Duoas with the turning off computer part - computers I think stifle creativity.
Turning off the computer is a metaphorical thing, for me anyway. Crayons and pencils aside, we do a lot of our ground work, requirements and design using tools (software ones, not hammers and chisels :-D), even for the small projects.
The trouble is all the licenses add up to being quite expensive, but we need them to exchange data with our customers.
I have to say there are pluses and minuses with using these enterprise level applications. The plus side is the amount you can do with them, from producing very professional looking documentation very easily, to quickly identifying 'gaps' and omissions in your design plan. The minus side is the overhead with using them, the big ones need to be configured and administered which in our case keeps someone gainfully employed virtually full time.
To use them effectively you also need quite formal development processes, and then you need processes to control the processes. Yes, it sounds very bureaucratic but it works very well and we can predict very accurately what resources are needed to complete the job in a given time frame. I still get my pencils out occasionally :)
The trouble is all the licenses add up to being quite expensive, but we need them to exchange data with our customers.
I have to say there are pluses and minuses with using these enterprise level applications. The plus side is the amount you can do with them, from producing very professional looking documentation very easily, to quickly identifying 'gaps' and omissions in your design plan. The minus side is the overhead with using them, the big ones need to be configured and administered which in our case keeps someone gainfully employed virtually full time.
To use them effectively you also need quite formal development processes, and then you need processes to control the processes. Yes, it sounds very bureaucratic but it works very well and we can predict very accurately what resources are needed to complete the job in a given time frame. I still get my pencils out occasionally :)
Topic archived. No new replies allowed.