I don’t understand what the starting point is. Do they just open a word document and start creating lines of code or is there some type of program that’s specifically used?
In: 1291
From my perspective as a software engineer, all of “my” software stated as an **idea**. A thought, a poem to be made into a pattern that is reproducible.
In short, the guy who pays you and your team will say that he (or someone he paid) had a “thought” on how to do something, and the very first part of the program is to document this “thought” and converting it into bits and pieces of reality, that is, **things** that can be done in logic that can be executed in hardware (the computer, or the machine, or the process) that can eventually be made to represent the thought or idea in a way acceptable to the guy who pays you and your team money.
SOMETIMES the very first part of the “program” is a short quick and dirty piece of software that can simulate the response the guy or guys that pay you. But in larger companies, it it almost always a DOCUMENT in some word processing type that in more sophisticated systems this DOCUMENT has links to other DOCUMENTS that are used to test to see if the “thought” is based in any sort of reality (sometimes, it is very much NOT based in reality) and is “valid”.
Those initial DOCUMENTS are linked with each other so that we have a way to test the software and verify the software – It is not always easy, because maybe the “thought” is something many programmers don’t understand by themselves.
Other DOCUMENTS are the list of tools and plans on how to implement the “thought” – the software tools, the types of hardware, the look and feel, and all of these DOCUMENTS will be reviewed by the idea guys (and yes, they make even more DOCUMENTS from the reviews) to make sure the “ideas” are represented are what are expected.
I’d recommend that even if you are programming your own ideas, that you get in the habit of starting with a document, even if its a crude representation of your thoughts and ideas, it will help you later. For example, it will give you experience in representing someone else’s ideas as a document.
True story: I was once in a meeting with 2 of the best programmers in Silicon Valley, discussing upcoming work – planning on making new documents to kick off a new project. We were finishing, when the “guy who pays everybody” walked in and sat down. He was an “idea guy”, some of his ideas were very valid and profitable. Some were not. But he sat there until I ended the meeting when he took his pipe out of the mouth and gestured over the table, to no one in particular, and stated, “There is one MAJOR problem with your software!”
Without prompting, both the programmers sat back down and opened up their notes. We sat and waited, “idea guy” had put his pipe back in his mouth and remained still. So I gently prompted him to share this “MAJOR problem” with the team, and he pulled the pipe from his mouth, waved it over the table and said “Whenever the power is off, your software loses control!”
Many thoughts went through my mind as I considered a reply. Why don’t I like the smell of roses? Can a urinal be redesigned as a standing toilet? Can gravitational lensing focus a beam of particles and photons and destroy the Earth? Which night class would give me the best chance to meet girls?
While I pondered for those very long seconds, neither of those programmers burst out in hysterical laughter. The both behaved like true professionals, dropping their heads down, one, writing precise lines in bundles of 4 and then crossing them out with a diagonal. The other was studiously writing loops over and over until the edge of the page, the starting a new line of loops. But they were using their documentation skills to forestall the most appropriate response until I came up with a proposal to create a battery backup for all of our desktop and embedded systems to extend the period before the inevitable “software failure due to power loss” became a problem.
However, had this “idea” could have been reviewed in a document form BEFORE publicizing it to others, then a lot of tongues would have been spared such severe bites.
In short, if you want to create a complete program from scratch, I recommend you first and foremost learn how to DOCUMENT the process first. The document will help you to work with others in the future.
Latest Answers