Earlier quoted context omitted.
Wait, flamewars about spaces vs tabs are part of a conspiracy to keep programmers insecure and frightened? You'd better explain that remark.
Executives don't care about that specific flamewar (or even know that it exists) but they like creating environments where we slug each other over minor, superficial differences in coding style because (a) it makes us look stupid and petty, and (b) it tires us out and makes us even easier to steal from. Programmers are often oblivious, when they find themselves in work environments that are designed to play divide-an…
Too scared to write a line of code
111–120 of 130 posts
Re: Too scared to write a line of code
#112I remember when Facebook's front page code leaked. I am no PHP expert, but it was pretty ugly code. Probably today you couldn't get hired at Facebook if you wrote code like that. http://techcrunch.com/2007/08/11/facebook-source-code-leaked... I've heard many arguments where people will tell you, it won't scale. Or you're doing it all wrong by writing quick and dirty procedural code. Quite frankly scaling is about the…
What's so ugly about it? It's easy to understand which for me is the single most important thing when writing code.
Re: Too scared to write a line of code
#113I often share a similar sentiment with teams I work with: Don't throw solutions at undefined problems.
That commonly applies to performance and premature optimization.
I'll agree that there needs to be some thought as to what's being built before, and while, doing so, but spending time resolving as-of-yet-undefined problems means decision making based on high levels of uncertainty.
Get something working and let problems define themselves. Often times, they do so in a way that makes them easier to fix vs. relying on the speculative solution making I mentioned above.
Re: Too scared to write a line of code
#114The thing is if you don't do it right with first go you will have hard time to get it done later. What management cares if it works, it's your responsibility to make it right from the start and they probably won't give you time to make some refactoring/optimizations later, because time is money :(. Sometimes it's hard to explain consequences. I have seen this too many times.
I believe you need to find golden middle, by not trying to hack things to much or overengineering problem, though sometimes is hard to define where is this middle.
Re: Too scared to write a line of code
#115I'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…
Be careful going overboard with pure functional programming. It could become one of the immobilizing factors the blog was talking about. Is the code pure FP? Can I get rid of the states? Am I doing correct FP? Should I write generic function for more abstraction? Am I doing DRY enough?
Re: Too scared to write a line of code
#116Does that resonate enough for you?
Seriously, seeing stuff black&white is how bad code happens. (And so many other things in life.)
Re: Too scared to write a line of code
#117This is really kind of the whole idea behind the "red, green, refactor" mantra. The point isn't to write perfect code right out of the gate, it's to write working code. Once the test is green, then you can refactor as necessary with the confidence that you aren't going to accidentally break things (as the test will backstop you). Ironically, I think this is something that affects seasoned programmers more than new on…
Also kind of related - programming by "wishful thinking". You first lay out the flow of the program as calls to high level functions which don't yet exist, and then go back and fill in the functions as you can. The first few SICP video lectures are all about this style, and I found the idea simple but very useful to avoid trying to hold too much of a problem in your head at once.
Re: Too scared to write a line of code
#118Earlier quoted context omitted.
Wait, flamewars about spaces vs tabs are part of a conspiracy to keep programmers insecure and frightened? You'd better explain that remark.
Executives don't care about that specific flamewar (or even know that it exists) but they like creating environments where we slug each other over minor, superficial differences in coding style because (a) it makes us look stupid and petty, and (b) it tires us out and makes us even easier to steal from. Programmers are often oblivious, when they find themselves in work environments that are designed to play divide-an…
Re: Too scared to write a line of code
#119Earlier quoted context omitted.
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 defi…
One screen is way too big! Make each function do a single thing. Even in verbose languages, you should be able to get most of them down to 5 lines or less - and this isn't actually difficult (except for coming up with names for all of them) the transformation is actually very mechanical, so much so that if you're using an IDE it can probably "extract method" for you, but even doing it by hand is trivial once you get…
Though at least for me there is somewhere a limit (2-3 lines?) where the returns start to diminish - there's more noticeably more typing involved, and more mental context switching while debugging.
Re: Too scared to write a line of code
#120Earlier quoted context omitted.
This is like in go. If your walls are too brittle, play more conservatively. If your walls are too thick, loosen up. You can make generally better moves in go just by recognizing if you are too conservative or too aggressive. Same with poker.
Upvoted to make up for MBlume's mistake. :)