Live data from Hacker News

Too scared to write a line of code

medium.com

111–120 of 130 posts

Re: Too scared to write a line of code

#111

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…

Please seek out a therapist to talk to. You can't be happy with the level of anger and resentment that you seem to have right now. At first I thought you were an attention seeking jerk, but after reading your comment history, I think you have gotten yourself into a bad place in life. Please consider it.

Re: Too scared to write a line of code

#112
post #9

I 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…

https://gist.github.com/nikcub/3833406

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

#113
Build it, release it, analyse it and only then decide if it needs optimising.

I 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

#114
"Build it, release it, analyse it and only then decide if it needs optimising." I think it depends from company culture.

The 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

#115
post #101
post #29

I'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?

Indeed. It's about knowing what tools are best to use when. My comment was more about how some (albeit not all) of the concepts of functional programming can help tackle the first few stages of larger projects and can often help to lower the chances of spaghetti code.

Re: Too scared to write a line of code

#116
There's a freaking huge difference between double checking every single line of code, and coding a new features (hundred, thousand of lines of code) with a scalable design.

Does 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

#117
post #2

This 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.

I've found what I think is the SICP book, but I can't track down the video lectures - can you provide some links? Thanks - I thought I was the only one programming by "wishful thinking"!

Re: Too scared to write a line of code

#118

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…

So, basically, your comment has nothing to do with this article?

Re: Too scared to write a line of code

#119
post #91
post #57

Earlier 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…

Indeed. 25 is the maximum - mostly the shorter, the better.

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

#120

Earlier 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. :)

Upvoted again, because I felt like it. But it's still one upvote short, I guess.
Post reply on HN