Live data from Hacker News

Organizing complexity is the most important skill in software development

johndcook.com

181–190 of 286 posts

Re: Organizing complexity is the most important skill in software development

#181
Yeah this is so true.

I worked on a system where we had to support imperial and metric units. It was done in a pretty bolted on fashion with if statements all over the place. And sometimes it isn't even clear if it could be done in any other way.

Any HN'ers have suggestions on how to do it elegantly.

Re: Organizing complexity is the most important skill in software development

#183

Earlier quoted context omitted.

Why's that? I've been thinking about starting my own side company. It is a lot of work!

Part of it is social and general anxiety. I'm afraid of putting myself out there, having my ideas and implementations judged, and finding both coworkers and customers. Part of it is having trouble focusing on a single idea. Finding the right partner would help here: see #1. Part of it is fluctuating levels of depression sapping my motivation outside, and sometimes inside, work. I have been fighting this for almost a…

Where are you located, and what are your qualifications? I'm NYC, Python/full stack. Email me!

I'd be interested in working on a project together (I have a recent "good idea" but it will need to be built ground-up). I don't have a lot of money, but I'd be fine with putting some capital down for hosting, domains, etc..

It would be very casual. No pay either way of course. Ownership is something to discuss.

For your first part, I feel everyone has that to some degree. You just have to do it. Email startups.

Re: Organizing complexity is the most important skill in software development

#184

Earlier quoted context omitted.

Why don't you join forces with your friends? If your tech is as far advanced as their business development, it sounds like you could join as an equal founder.

Well, they're pretty sold into their idea (which doesn't interest me) and they have one or two other people involved (so I'd be coming in as an outsider anyway). I've met their developer once and he seemed like a nice guy, though very inexperienced (not to speak ill, he's just young). So basically, they have a team together and I don't want to break them up, before their time, if that time should ever come. Some of i…

No idea where you can find that business guy. That's a great question/problem.

Re: Organizing complexity is the most important skill in software development

#185

Earlier quoted context omitted.

It would be actually interesting to look at the commits of a candidate's any online project repository from the very start and observe how the candidate made the progress with respect to the structure of code and improvement in coding practice. To check whether the candidate optimizes and refactors the code during the development of the project leading to a stable release.

This assumes that developers' off-work behavior is similar enough to their work behavior that it's a reliable indicator of their workplace performance. Or that developers should comport themselves on their off time to a workplace-level standard. The problem with this is that it doesn't let my personal projects be Play. If I'm writing something for myself, it's not going to be as clean and documented to the level it w…

Yeah, personal projects could be sloppy, as it's mostly for learning new technology. And it may also be unfair to say that a good programmer always produce clean code, no matter the reason for development.

But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he/she has motivation to do best. If the employer can just ask the candidate for that project, and the candidate can show that project in a public or private repository, this would give really important insights to the employer about the candidate which would be beneficial for that both.

Also, this doesn't mean that the candidates who doesn't have public repository to show have any disadvantage, they are at the same point. Its just that the candidate who is able to provide a project of his choice through public repository would be a few points ahead other candidates.

Re: Organizing complexity is the most important skill in software development

#186

This has been my experience too. I've been involved cleaning up a half dozen or so projects that got out of control. In each case, technical complexity was blamed as the reason. After digging in, I found that following commonalities: - Incomplete, conflicting and misunderstood requirements. - Lots of "We never thought we would need to do X". - Poor team communication. - Mistrust, frequently well earned. - Harmony val…

Cleaning up buggy legacy code is a goldmine for learning what not to do.

Re: Organizing complexity is the most important skill in software development

#187
post #28

Earlier quoted context omitted.

> Sadly there's (seemingly) no way to interview people for this ability In a recent interview, I spent 45 minutes pairing with a current employee. Our goal was to take a (contrived) piece of legacy code, clean it up, and add a new feature to it. I imagine it was a very telling experience for them, and I feel it was more useful than the whiteboarding we'd done before. Hopefully we as an industry will keep iterating on…

Yeah, a combo of a scanning a candidates github projects and some doing some pairing on real code is much better than whiteboarding.

Except not all of us keep our stuff on github.

Re: Organizing complexity is the most important skill in software development

#188
post #79
post #28

Earlier quoted context omitted.

> Sadly there's (seemingly) no way to interview people for this ability In a recent interview, I spent 45 minutes pairing with a current employee. Our goal was to take a (contrived) piece of legacy code, clean it up, and add a new feature to it. I imagine it was a very telling experience for them, and I feel it was more useful than the whiteboarding we'd done before. Hopefully we as an industry will keep iterating on…

Yeah, that is cool and lets you get a hand on the job and a feel for what you'd be working on, but it makes me a little wary. Doing work for some employer without getting paid is a red flag. It's not a total klaxon blaring, but it does raise eyebrows.

I would hardly consider that "work".

Re: Organizing complexity is the most important skill in software development

#189
post #99

Earlier quoted context omitted.

Agreed. Nowadays, writing the runtime environment including a concurrent garbage collector is more complicated than writing the compiler.

When you say concurrent, do you mean "works with threads" or "doesn't pause"?

It's both. If it doesn't work with threads, there is no concurrency.

If the threads have to stop, it's still concurrency in the sense that threads are stopped in arbitrary places (just like an interrupt can stop a task at any point in its execution and dispatch another task or whatever).

But the garbage collector isn't running concurrently with the threads.

I.e. I think the term "concurrent garbage collector" is understood to be in contrast with "stop-the-world garbage collector" not with "synchronous garbage collector as a library function in a single-threaded virtual machine".

Re: Organizing complexity is the most important skill in software development

#190
post #103

Or in other words: code should be as simple as possible, but no simpler. I guess you could call it organization or readability or just good design. It requires deeply understanding what you're trying to accomplish and structuring your code to reflect that. I don't think there's any rote, step-by-step procedure that will get you there. Often it is a flash of creative insight that breaks the log-jam and reveals the hid…

Developers understand the word "simple" in different ways. I personally think of the UI/API: what the code exposes to the outside world should be "simple". Some people might think about language features. "Simple" is being very selective about what language features you use and what you avoid. Others might think design patterns, and think the code is "simple" when you can point to any class and immediately recognize…

I was thinking of more than the UI/API, although I agree that should be simple as well. I think the internals of the code should be simple, in the sense of being constructed out of simple parts with each part being simply connected to the other parts. This means each method should have a clear purpose and it should accomplish it cleanly without surprising side-effects, and that the flow of method calls should be straightforward.
Post reply on HN