This calls to mind what Zed Shaw wrote about creative and defensive programmer mindsets. http://c.learncodethehardway.org/book/ex27.html
Too scared to write a line of code
51–60 of 130 posts
Re: Too scared to write a line of code
#52There's another approach from polya's how to solve it. If your problem is too hard to solve, find an easier related problem and solve it first. Which I guess is sort of like applying an MVP to parts of the project as well as the whole thing.
Re: Too scared to write a line of code
#53Earlier quoted context omitted.
Sometimes I'm surprised at the lack of parallels between writing long-form articles and writing code. How many people draw a general outline of their program, what they want each part to do, and how the whole thing should be layed out? Who plans before they start coding it?
Code is a planning language, so rather than boxes and noodles or pseudocode, I tend to sketch out my plans in code itself. In SICP this is called "design by wishful thinking": you pretend that you already have a library of primitives that do the nitty-gritty work and write the high-level bits of your program using those primitives. Then, you go back and implement the primitives. It's surprisingly effective.
> "design by wishful thinking"
aka coding by intention
Re: Too scared to write a line of code
#54Earlier quoted context omitted.
Sometimes I'm surprised at the lack of parallels between writing long-form articles and writing code. How many people draw a general outline of their program, what they want each part to do, and how the whole thing should be layed out? Who plans before they start coding it?
I think these types used to be derogatorily referred to as "cowboy coders" in the 90's by overly process oriented developers who came from an era of mainframes and punchcards. I think a big shift in modern software development came about when people finally realized that developing software is by nature a "messy" process. Loose text files, REPL sessions filled with red lines on the console, randomly scribbled boxes w…
> .. messy ..
Design is messy. The implementation need not.
> “Design Patterns”, “Code architecture”, “Scalability”, “OOP”, “Maintainability”
Apart from Scalability others can be implemented from day one.
Scalability is about a dumb proxy first. Change in Data structures next.
In software, you have two choices.
1) Dumb code that works aka kludge.
The author is advocating kludge programming.
(I want to use this word distinctly from hacks, which are fewer and atleast clever)
I advocate this.
2) SQlite, Games
I advocate this too. Software that is meant to last, requires rigor.
My point is, the author is considering all programming to be engineering programming. It's not. And I do hate project managers that confuse the two.
I even concede that you can mixmatch the two (testing for eg). Why don't people see this middle ground ?
Re: Too scared to write a line of code
#55It's an oldie but a goodie. Fred Brooks:
"Plan to throw one away. You will anyway."
The mistake most people make is that they mix learning and doing in a single round. It's much better to write a prototype with a specific goal of wringing as much knowledge from it as you can without being distracted by scalability or maintainability minutiae. Then, and only then, will you be ready to write The Real Thing with all of the bells and whistles. In the end you'll probably save more time than if you kept going back and forth waterfall-style between learning and doing on the same codebase. You'll certainly end up with a better result.
P.S. That quote is from 1975. To quote another great mind (Santayana): those who do not know...
Re: Too scared to write a line of code
#56I'm by no means a pure functional programmer, but I've found some of the mantra from that paradigm helps when building the early blocks of a program as it allows you to break down your application into core problems which can be tackled individually. Plus it allows your application to scale easier and makes it easier to rip out and replace code as you start to add complexity. But of course, before starting any major…
in other words, FP evolved to solve hard problems. You don't need to understand monads to model a cash register. You probably do need monads if you want to write a bug free distributed asynchronous system.
> bug free distributed asynchronous system
Have to add bugs to haskell code ?
gosh it seems impossible.
Re: Too scared to write a line of code
#57I don't know--my impression is that most people go to far in the other direction. They write code with no thought at all for the future, and then shortly have nightmarish debugging sessions in spaghetti code that's impossible to extend or reuse. All in the name of a rather extreme "worse is better" philosophy. I've certainly experienced this with some of the people I worked with recently. Anything you win in the shor…
Great advice IMHO. One trick that I found useful for myself (good chunk of my code is "hobby" code that I myself revisit some months later, so not really "production" problem but nonetheless almost the real-world maintenance example):
- make the function fit in your head. Literally. Make it fit in one screen, if you can. If it does not, think how you can make it fit on the screen - everything, including variable definitions.
- avoid branching as much as possible unless it is the 'exit' branches. Avoiding branching sometimes can be done by tricks like passing function pointers. Do it - it makes code much more expressive and easier to read.
These two heuristics allow me to make the code much simpler to understand for $(me+6months). I saw the same patterns in real-world code at $work as well - using the above two principles makes the code dramatically easier to support later.
Re: Too scared to write a line of code
#58The Bad Guys want you to feel insecure about your work, your position, your relative standing, and everything else because their worst nightmare is that software engineers and scientists and thinkers wake up and realize how much leverage they would actually have if they were organized and capable of looking out for their own interests. We'd reshape the entire business landscape, and the power relationships between us and them would be inverted.
They prey on the insecurity of the smartest people. It makes us easy to take advantage of, and compromises almost all of our leverage.
Every time you let them sit in your head and natter about how your work isn't good enough because it doesn't isn't in accord with what they see as "professional", you're letting them win. The problem with assholes is that their imprints live on even years after you get away from them. It takes conscious effort to get that lingering cognitive load out of your mind.
We need to step back and simplify: solve problems, and do it well. (This includes documentation and testing, when appropriate.) Make stuff, make it good, make what's good better. We need to get back to that, rather than slugging it out over "agile" and TDD and nonsense. Zed Shaw got it right: http://programming-motherfucker.com/
Re: Too scared to write a line of code
#59Earlier quoted context omitted.
Using a visual git client greatly helps with this approach, especially if you are coding in multiple files at once. Once you have "green" status, look over the changed lines in the git GUI and look for lack of patterns, code smells, etc. This separates the coder in you from the reviewer in you.
Perhaps I'm misunderstand you, but what difference do you see for this use case between visual and command-line git clients? I do this all the time with git-diff on the command line, and it might just be a failure of my imagination, but I can't think of how the process would be any different with a visual client. Can you give an example?
Different strokes. I'm like you: I do a git status from the CLI for peace of mind. Others in my company gotta have their SourceTree, and hate the CLI. I disagree, but it's their choice.
Re: Too scared to write a line of code
#60you need to learn calculus if you want to model relativity. you only need fifth grade math to model a cash register. if your team builds apps with 500k LOC, you need to be constantly focused on abstracting and factoring out patterns or you will drown in your defect rate before the project even ships. If your team builds medical device software, if you aren't doing this, you'll get someone killed. If you're building a…
Of course. And to add an example of the other part of spectrum (opposed to medical device software) - bunch of simple 2d game prototypes. There's people who do such jobs, and many similar, who'd be a fool not just "push the buttons" all the time, with basically just a quick forethought related to structurization and code quality.