I was just wondering if the people who work on real world projects write their code from scratch. I also want to know the how the web developers start off with their code. If an experienced web developer can shed some light on their thought process would be of some help.
While I am not a real life web developer, I know a few.
They rarely write anything with pen and paper Usually there are some scribbles on whiteboards - a todo list, but mostly they interact with no other tools than software.
In real life projects are either extremely massive and you will be assigned a task similarly to FCC (eg. ‘build home page front end, then pass the code to programmer X’) or so small that you can start however you want.
My technique (and I know many people who do the same) is to build the basic back end functionality, then open a photo editor (photoshop, gimp etc.) and do a rough sketch of what I want the front end to look like. While it’s rough sketch, I try to find the fitting color palette that remains (mostly) unchanged throughout the project. Usually I position the elements in the editor as well.
Then I forward the sketch to my second monitor and code whole front end without yet connecting it to the back end.
And when I think that I did good enough, I connect everything.
Then what is left is just polishing: removing debugging messages, writing more readable comments, changing code here and there.
Other people start with front end, but most of the programmers I know sketch the thing with photoshop beforehand to know how it looks and feels.
Write the actual JS/HTML or CSS or [whatever] code on a piece of paper?
Last time I did that sort of thing was in college, programming an Apple ][ computer (AppleSoft Basic) because computer lab time is limited, and we didn’t have a computer at home. So I need to think and write my code in advance, and just use computer lab time for data-entry and debugging.
But No… that would be a waste of time.
Plus modern editors have auto-completion, Intellisense so you minimize typos when you re-type variable names, or code completion gives you suggestions on what to write next, or displays a hint of parameters that’s needed for the function you’re calling.
For coding, I start writing out comments that are pseudo-codes. This gives me a map of what I need to do, step by step, going from the big general picture (the algorithm, solution to the problem). Then later on converting that pseduo-code to actual computer language syntax.
You can’t write the code, if you don’t know how to solve the problem in detailed, plain english.
Well, Ill be the odd one out and say… I do.
Not the whole thing of course, but when Im brains storming I do often start with a sketch and jotting down a very general guide of how I want to layout my design along with what divs go where. So Ill have a visual map to work off before I actually start the markup for it.
I often rough out my layout on paper, and I will rough out my logic (code) on a white board (or paper if I don’t have access to a white board)
They should. One of the most common mistakes that programmers at all levels make is trying to think and code at the same time. Take your fingers off the keys and figure out your logical solution first. This may look like an outline, a flow chart, pseudocode, whatever works for you.
I’m not a professional or full-time developer, but I find as cndragn and ArielLeslie mention that if I do ‘sketch’ out an outline on paper first, it helps me quite a bit. I’ve never written any significant software, just odd scripts and such for work and hobby purposes. I’ve also played around with using some freeware mind-mapping software to get ideas solidified and I find it has merit as well.
Just diving in can be fun and can work sometimes, but you can bog down pretty quickly without a roadmap, and that applies to a lot of other things besides coding. Of course, you could do this in your favourite word processor instead of pen and paper, but I find physical writing comforting sometimes - I suppose I might be showing my age with that too , aside from the fact that I also remember writing code for the Apple II and waiting my turn to eagerly type it in
Like @owel said, writing actual code will be wasted time. If you can see the real code, you should just put it in a file now.
But… there is immense wealth to using pen and paper (or whiteboard, or post-its).
In this case, you have a trifecta. You think it (and probably hear yourself saying it). You write it. And then you immediately re-internalize it by seeing it.
That loop creates a multiplied learning effect.
For me, I do sketch/wireframe layouts, model API routes, and write potential requirements and pitfalls. Each page in my notebook is a single project with a date (for when I’m flipping through later for inspiration).
I also create sitemaps with post-its and an empty wall. Start by writing one thought on a note and put it on the wall… anywhere… nobody cares about order yet. Just get as many notes/ideas on the wall as you can think of. Then, step back and look at all of them. You’ll start to see patterns. This is where you start to move and group your notes. When you’re done, you’ll have a better picture of the requirements for a project. In UX, they do something similar called affinity diagrams, but this isn’t quite that involved.
Gets me out of my chair too. And movement is good for thinking.
I try to leave the notes on the wall for as long as the project runs. I’ll even add to them as time goes (and scope allows).
I’m not a full-time developer yet, but I find it really helps me to use pen and paper (or pencil and paper).
I usually sketch out an initial rough drawing of my project design, then break it down for myself into what I want each piece of the project to do, and yes, I do start writing my code on paper Especially if I’m trying to work out a certain portion of code in a project, I’ll take a break from staring at the computer and start coding on paper. It helps me think through how the code runs and what it’s doing at certain stages, then usually I can figure out what I need to do.
I also keep track of my progress in a project, either on paper or in OneNote, and it really helps me to see where I started, and how far I’ve come. Currently I have several notebooks filled with my first thoughts and sketches and project notes! So for me, I’ll probably always use pen and paper
I never write code with pen and paper, if I need to keep notes, they are either in comments in the source code, or in extreme cases a Google Docs Document.
To be fair at technical interviews you’ll be writing code on a whiteboard so you might wanna get one to practice on.
Not the code though, but i still use paper (writing pad) to get a general outline/functionalities/features of what i expect from the project…i do this especially when I am on the move without access to my laptop…yeah, most of my web dev ideas come when I’m not sitting in the front of my PC.