Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Confessions of an Intermediate Programmer

michaelbromley.co.uk

Post reply on HN
Print view View original

111–118 of 118 posts

Re: Confessions of an Intermediate Programmer

#111

Post by doktrin »

Nursie wrote: post #91
doktrin wrote: post #29

Earlier quoted context omitted.

> &structure AFAIK, that's only a legal function signature in C++. To the point of the question : when I wrote that, I was specifically thinking of 2-dimensional arrays, not structs per se.

I meant passing a pointer rather than a by-ref call (which is indeed C++ only). i.e. void myfunc(thing* stuff) { return; } int main() { thing stuff; myfunc(&stuff); }

Oh, totally agreed. What I had difficulty with, specifically, was passing around a struct that contained a multidimensional array of a size determined at runtime.

I'm sure the problems I had could be solved by either a full re-design (not really an option), or accomplished by someone with more C experience.

Re: Confessions of an Intermediate Programmer

#112

Post by ufmace »

esonderegger wrote: post #32
sdrothrock wrote: post #3

Earlier quoted context omitted.

It's normal but can be really, really scary if you don't have a mentor or someone to help you out or point out some of the pitfalls on the way. Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you…

What's worked for you all for making the leap from lone programmer to working on a team with a mentor/people who are smarter than you? I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm…

I've been there. As far as testing goes, my vote is that, when you're at the beginner level for a framework/language/technology, put off testing until later. Get it to work normally first, and then write your automated tests later.

You already have a hard problem on your hands, figuring out how to get something to work normally in this new environment. Don't compound that right off the bat by trying to learn a new testing system too. In addition, reality is the ultimate test. By getting it working normally first, you know that it actually works, so if you write a test against it, and the test fails, then the test is probably wrong.

Once you get good with it, you should be able to reverse it and go to a more TDD-like workflow - write tests and code first, then manually test, and have confidence that if the tests work, then the app will work for the users too.

Re: Confessions of an Intermediate Programmer

#113

Post by ufmace »

nikster wrote: post #99
gedrap wrote: post #36

From both my own experience and witnessing others, one major factor that sets apart from beginner and expert is working with legacy code. And by legacy I mean legacy from previous developer, previous team, whatever, not necessarily a decade old code base. Beginners are keen to get rid of all the legacy code. It's tightly coupled, it's hard to read, hard to maintain, yada yada yada. And then they tend to make a way to…

Experienced programmers refuse to take the job. We once tried to contract this really fancy team to take over some code. They asked if we had unit tests. "No". "Then we can't do it, sorry, bye." And I agree with them.

Really fancy, hmm... They strike me as being not very useful if they aren't willing to touch the code unless it meets some quality standard. I can understand turning down a contract if the code is total mess and the client wants major work done in an unrealistic amount of time or for too little money. In this case, why not reply more like "We're going to have to do some refactoring before we do X. If your budget allows for that, then we'll take the job."

Re: Confessions of an Intermediate Programmer

#114

Post by tautvidas »

nikster wrote: post #97
ameister14 wrote: post #14

For me the thing I had to learn was commenting more than anything else; working alone I never saw as much use for it. Then I worked with a guy that commented his code very well and suddenly I saw massive value in it. I'm definitely still an intermediate programmer, but I think I was always fine admitting that to myself. It was getting over the fear of others reading and modifying my code that took me a while.

Yeah well... Great code needs no comments. Bad code needs lots of comments. I've seen examples of both recently. I randomly met a guy who told me of his idea to implement a UX framework with windows, buttons, views, etc in python. A week later he sends me the finished framework. And it's perfect. It's easy to understand, all the names of things make sense, it's orthogonal. Not a single comment anywhere, but perfectly…

While I do agree to some extent that great code doesn't need any comments, it raises some questions. How can one be sure at the time of writing that the code is easy enough to understand for others? I'm sure that it's understandable for the author, who's been staring at it for a few hours, but will the same hold for a future maintainer?

I agree with other commentators that with comments one can at least express the intent and reasons for particular decisions.

And on a side note, it's wonderful to strive to write great code, but I believe it's easy to misjudge and think "Oh, I clearly write understandable code, thus I'll skip comments" even when it's not that clear. That certainly has happened to me, very likely to others at some point as well.

Re: Confessions of an Intermediate Programmer

#115

Post by lostlogin »

tbomb wrote: post #108
habosa wrote: post #54

This article did an excellent job verbalizing the incredible feeling of mental potency one gets when learning to program. When you see that first "Hello, World!", you are hooked. I still get this feeling whenever I learn a new platform. When I learned Android I was amazed that I had made a real-life app run on my phone. When I learned Ruby on Rails I proudly stuck my flag in the surface of the internet and declared m…

It's such a great feeling. My favorite part is how, no matter how long you've been doing it for, you still get that feeling time and time again.

That bit is good. Fixing a bug that has haunted you is even better. Everything I've ever made is pathetically simple, so I can't imaging how good it must feel to fix something that is actually complicated.

Re: Confessions of an Intermediate Programmer

#116

Post by spiffytech »

Denzel wrote: post #95
merry-year wrote: post #90

Earlier quoted context omitted.

NoSQL DBs have real advantages - e.g. you have a huge production relational DB, you want to make schema changes - you have to take your app offline for hours.

No. You can migrate big production relational DBs with much less than hours of downtime; sometimes there's no downtime at all. Please, either qualify your statement, or stop speaking in such an absolute sense.

Would you mind expanding on how to minimize downtime when applying migrations to large DBs? It's clear the grandparent isn't familiar enough with the relevant techniques to realize their statement needed qualification, or could count as "nonsense", so they could probably benefit from the explanation.

Re: Confessions of an Intermediate Programmer

#117

Post by ATLobotomy »

doktrin wrote: post #111
Nursie wrote: post #91

Earlier quoted context omitted.

I meant passing a pointer rather than a by-ref call (which is indeed C++ only). i.e. void myfunc(thing* stuff) { return; } int main() { thing stuff; myfunc(&stuff); }

Oh, totally agreed. What I had difficulty with, specifically, was passing around a struct that contained a multidimensional array of a size determined at runtime. I'm sure the problems I had could be solved by either a full re-design (not really an option), or accomplished by someone with more C experience.

It shouldn't matter what the struct is holding, you are passing a pointer, it's always the same size.

Re: Confessions of an Intermediate Programmer

#118

Post by Denzel »

spiffytech wrote: post #116
Denzel wrote: post #95

Earlier quoted context omitted.

No. You can migrate big production relational DBs with much less than hours of downtime; sometimes there's no downtime at all. Please, either qualify your statement, or stop speaking in such an absolute sense.

Would you mind expanding on how to minimize downtime when applying migrations to large DBs? It's clear the grandparent isn't familiar enough with the relevant techniques to realize their statement needed qualification, or could count as "nonsense", so they could probably benefit from the explanation.

Sure, it can be accomplished in a variety of ways: swapping a migrated replica; breaking big schema changes into multiple incremental migrations that minimize the amount of time the database is locked and back-filling data; or spinning up an entirely new cluster, migrating everything, and then switching traffic over from the old cluster to the new cluster at the load balancer. Any number of these techniques can be mixed and matched to accomplish minimal and/or zero downtime depending on your constraints. [1] The most important thing is making sure your application code is able to operate with multiple schema versions.

I used to have a presentation from Facebook where they spoke about their zero-downtime migration process, but I can't find it, so this SO post [2] will do. Of course, there's a bunch more information out there to read up on.

[1] https://www.honeybadger.io/blog/2013/08/06/zero-downtime-mig...

[2] http://stackoverflow.com/questions/6740856/how-do-big-compan...

Post reply on HN