Live data from Hacker News

Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

news.ycombinator.com

81–90 of 126 posts

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#81
post #19

While this doesn't directly answer your question, but I've found edw519 (a fellow HNer's) past comments on this subject highly enlightening. If you're looking for something inspiring / actionable to read, checkout this collection by him http://v25media.s3.amazonaws.com/edw519_mod.html One of my favorite answers - 71. How do you get good at programming? I believe that there are two ways to get good at anything, "push"…

Wow, excellent answer. I would add that if you're a "pull" person, don't bother applying to the Googles and Facebooks of this world. Their hiring process is extremely oriented towards "push" learners, presumably because you need lots of those people to build something at that enormous scale. Instead look for opportunities where you get to do something you don't really know how to do. (There's a number of reasons why…

I'm a pull engineer, and I work for a big, recognisable SV firm. I agree that hiring is fairly heavily biased towards push-types, but if you accept the premise and spend some quality time with some text books and online classes, you can come a long way (think of it as pull: if the goal is to work for Google, this is probably what you need to do).

One thing is for certain, carrying around a chip on your shoulder because you didn't go to Stanford will do you absolutely no good, and probably be a net negative for your career (and happiness in general).

For the record, no, working for Google and Facebook isn't the single only answer to life, the universe and everything, there are plenty of perfectly worthy paths that don't lead anywhere near them, and there's no shame in taking them. But they are juggernauts of our industry, they do pay very well, and for better or for worse, a stint at one of them does open a lot of doors.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#82
It sounds like you're working alone? Getting feedback is key to learning, and it's hard to do that on your own.

1. If you have skilled coworkers doing code reviews (or contribute to an open source project that does code reviews) you will get a lot more feedback.

2. Writing unit tests will provide some level of feedback, but it's not as good for learning as human feedback.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#83

For identifying strengths and weaknesses: "Programmer Competency Matrix": - http://sijinjoseph.com/programmer-competency-matrix/ - https://competency-checklist.appspot.com/ - https://github.com/hltbra/programmer-competency-checklist ... from: https://wrdrd.com/docs/consulting/software-development#compu... ) > How do I get good enough to consistently do work worth writing books about? - These are great reads: "The Arc…

[deleted]

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#84
To quote Ira Glass here: "Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take awhile. It’s normal to take awhile. You’ve just gotta fight your way through." Ira Glass

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#85

To quote Ira Glass here: "Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your wor…

This is like notch and minecraft. I was on the javagaming.org forums with notch for many, many years playing his little games and experiments. You can't look at the finished product and have any idea about the real work that went into it.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#86
I also do iOS apps, and I think the reason for bugs and low maintainability in our domain (i.e. programs that have to power a GUI and all its states) is convoluted state. You stack feature upon feature, and once the system gets big enough, it's getting hard to get a proper grip of what is actually happening. So you start monkey patching, and you start to regret not having written any integration tests that would tell you when you introduce regressions.

State has to be managed rigidly. If you cannot deduce what semantic state your app is in while you debug, then chances are things will go wrong.

I have found two approaches that work for me: Reactive programming, and good old state machines. The former is needed when there is so much state that the latter would be too complex (too many possible permutations > too many states to grasp).

Every property that your screen has (element A is hidden, element B has this text, animation C is in flight...) should be derived from the current screen's state machine or stream of values. Meaning, state 1 will set A to hidden, B has no text, and C is stopped; state 2 will set A to not-hidden, B has text "xyz" and C is still stopped, etc. It's kind of like React, but on a lower level - properties are overridden or methods are called when transitioning between states. One could call this state machine "ViewModel" :) Swift brought us Enums with attached values, so they are perfect for modeling a state machine. IMO Optionals also prevent some state sloppiness we had with Obj-C's nil behavior.

I'm not saying state machines or Reactive programming are a panacea, but they have solved the problem for me. I'm confident in my code now, and have the feeling that I do solid work (which is good as I'm huge on feeling like an imposter). As long as I use Swift and RAC or state machines, the very most bugs I cause are of semantic nature - e.g. a button text is wrong in such and such state. But crashes or unreproducible behavior are really rare now.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#87
post #19

Earlier quoted context omitted.

Wow, excellent answer. I would add that if you're a "pull" person, don't bother applying to the Googles and Facebooks of this world. Their hiring process is extremely oriented towards "push" learners, presumably because you need lots of those people to build something at that enormous scale. Instead look for opportunities where you get to do something you don't really know how to do. (There's a number of reasons why…

I'm a pull engineer, and I work for a big, recognisable SV firm. I agree that hiring is fairly heavily biased towards push-types, but if you accept the premise and spend some quality time with some text books and online classes, you can come a long way (think of it as pull: if the goal is to work for Google, this is probably what you need to do). One thing is for certain, carrying around a chip on your shoulder becau…

Undoubtedly. A stint in the Navy can be very helpful if you plan to be a pirate.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#88
read clean code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

and clean coder https://www.amazon.com/exec/obidos/ASIN/0137081073/metafilte...

If you follow the (admittedly pretty extreme) advice in these books you will be in the top 10% at least.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#89

I am in my late 40's, I have been coding since I began uni in 1987, I have a Computer Science degree. When I got out there 25+ years ago I was all about doing things the best way, code reuse, refactor etc to get things just right. Most younger devs are. It took so much time getting the environments perfect, unit tests, etc. The customer paid for that, my managers must have been tearing their hair out watching us faff…

I'm not sure where all this process came from, but it sure does cost the business a ton of money without much return. I would theorize it could be an attempt to abstract the developer from the business process so the business isn't so beholden to one or a handful of people.

On a side note, I embrace source control. It allows me to run down a rabbit hole and not worry about having to get myself out of it.

To the OP: Look at popular code bases and see how they are organized. Run your debugger through them and see how they work. Organization is the key to maintainability. DRY (Don't repeat yourself) and KISS (Keep it simple, stupid) are your friend. Like anything, the more you do, the better you will become.

Re: Ask HN: Maybe I kind of suck as a programmer – how do I supercharge my work?

#90

So one thing I don't see a lot of responses calling out, that I think is worth calling out, is what you see is how long the -code- took. You don't see how long the design took. You assume it started when the code did, but that may not actually be the case. These other developers may have had this idea in the back of their mind for months, chewing it over, thinking about how they'd approach something, doing research i…

Furthermore, there is no way of knowing whether the code you see is version 1 or version 10. Maybe they hammered away at local copies for months before finally figuring out the optimal design.

Well the OP explicitly mentions that he has been looking at the timeline between commits, so that point is moot. Even if some commits are missing, you can see the rate of change of the project - "invisible" offline commits would have a noticeable impact on the productivity of the "visible" one s in parallel.
Post reply on HN