i was not sure were to post this... as it is a general question towards all "problems", but mainly focused on programming.
I would like your thoughts how you approach a problem (in this case, Python programming... but any problem in general would do).
Because nowdays, whenever i approach a new thread in my main project i tend to start a flowchart. Though im the only one working on this project, but it sure helps me clear out and see problems arise before they actually do. I use a cheap (free) flowchart software to get my vision out there on the "paper", and get a good birds eye view of where to focus, or were to solve different tasks and to think more general of a problem and solve it as a general problem, for which i can apply on many places in the project.
Anyways, i just wanted your opinion on how you do it guys. I mean... are you throwing yourself at the keyboards and start programming and deal with the problems as they come along or do you have some sort of "brainstorm" before you do it ?!
I used to do it, just programming away and deal with it as the problem came along... but... yes, i have learned to have patient and get a better view of what i am actually dealing with, now. Many times, i have had to reprogram large portions of the program because the problem grows or get worse if i dont deal with it earlier. Ofc, that doesnt stop me from start out by "trying away" on different visions... just to have a look of how it develops. So i usually have a trash coding going on (from which certain ideas arise).
What say you ?
Post a Reply
|Oldest Newest Rating|
· December 19, 2014
Usually most of my coding is done at work.
I have a whiteboard in my cubical. I start by identifying all that I want the code to solve, and what tools I have to aid me (ie api's, databases, server resources) and start to divide the problem up. Then I will usually draw out the idea that i have to solve the problems in short pseudo code and build the general framework of my code (functions, classes, data structure, ext). After I usually will ask a teammate to look it over and see if they have any suggestions, or ways that can improve performance of the code. Once done, I will take each module of the overall program and code it, then test it. At the end I will put it all together.
After that, I start working on putting it into automation (chef cookbook)
The biggest thing is to build from a testing mind set. This book will really help you get to thinking about it in that way.
· December 19, 2014
Thanks for your input Stephen !
Your approach seems very ok indeed. Its always good to have partner for which to throw ideas and thoughts at/or with you. Flowcharts may indeed have different looks, from people to people, though there are for sure some standards regarding flowcharts in general.
The reason i bring it up, is because i have seen code (mostly in assembler) that visualize the hole code at hand by flowcharts, and it brings more light to the actual code. Also, any person without knowledge of coding can comprehend what is going on with the code, and why it responds as it does (though this might not be the actual truth, cause the flowchart is the vision or intention, and the actual code with its flaws the "real" truth).
I have more to learn towards Python, modules, databases and api:s... as im just a beginner at it. Though the concepts is showing in assembler and electronics as well. Meaning, to group up things that works good (have a good input and a good output, of its local concept).
I feel that its sometime so much information (coding, electronics, language) that mostly the job is about what to exclude, then what to include. Here assembly is easy... as the op-codes are few, but the work is a lot more, but logically easy to follow. But its really tough knowing what is going on within the Python modules... and if i should even care. But the problem is when things go wrong with Python and its modules. As within electronics, i mostly hope that it does what i think it does. At least with electronics you have tools to use and search for the problems.
The point is, am i the only one using flowcharts ?! (though Stephens concept is basically the same, generally speaking)
· December 19, 2014
Flowcharts are for documentation to reference later...... and usually something that nobody wants to do, so it usually does not get done. It's a lot of extra work to do flow charts in something like visio for the purpose of brain storming. Plus its not a very good tool for collaborating with others. Most people who are coding for a living are under a big crunch to get things done within their sprint, so that is just unnecessary work, especially when a whiteboard and a camera phone can do the trick fine.
· December 20, 2014
I have to disagree on that Stephen. Flowcharts are universal in that sense, so people... who are pulling the carriage, that is supposed to be the company can see what is going on were, and can so change the carriage so the workers pull in the same direction, towards the goal, objective, vision or whatever it is.
But what you say i true for many companies, the way i see it, companies that are doing it wrong. Can it really be hurried to strive for the vision ? Or have the company leaders forgotten the vision ? Or is there a hidden agenda ? Meaning, the only purpose is to get money for time spent ?
I have been (or still am from time to time) in your situation as well, but i dont work with coding, but instead working with automation and PLC, which is basically the same. Also, what is more common is the database. And databases needs to be handle with care or they are more or less obsolete, and actually makes more trouble then good.
So, yes when i am at companies, the flowcharts are never there. But i wished it was so. Why ? Because its really tough dealing with people who have had the same work for >10 years. They have really hard to see what people from the outside see or fail to see. A flowchart that can be clicked (zoomed in, like a tree structure, or web browser) really is the thing Stephen ! Why ? Ever heard of ISO standards ? Accidents at work ? People fail to see the workflows and such. A good flowchart is a no brainer.
Anyways, i do not see it as extra work, i really dont. Most work meetings are not necessary if you could represent your work graphically, like a flowchart. The problems, time consumers would really stand out visually. And more then often, is the job at work about copying works that have more or less been done. The problem is to know which parts to copy. And if one had followed through with a good graphically explanation of the building blocks (code functions, in this case) then one could just work with the graphical interface only, and the coding to be done automated. One example, can be a website editor with templates... the user, never really sees the code, but are designing instead with code chunks. Another example are electrical schematics or water circulation charts... economics... the usefulness is there, within a flowchart. Actually starting from scratch, with nuts and bolts, as is needed by the ISO standard (to explain a workflow, so everyone know what to do, when to do, whenever they do). But it mostly consist of endless texts with paragraphs.
This section is all about snakes! Just kidding.
|Bucky Roberts Administrator|