Organizing complexity is the most important skill in software development • Hacker News Board

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

#191

Post by anowell » Mon, Jun 22, 2015, 7:08 PM UTC

msandford wrote: post #7

This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features that would have been impossible on the old code-base. It turned the job from hellish (features were impossible to add) to very nearly boring (there wasn't much to do anymore). So with this newfound freedom I built some machines to automate the data entry and on…

There's a lot of hate for whiteboard coding. Having been on both sides of whiteboard, code reading, and code pairing interviews, I like them all for different reasons:

Code reading: In Whiteboard: in ~15-20 min I can get a grasp on how someone takes a vague problem and works toward a solution and how they are to work with. I'm actually less concerned about code, and more about how they handle ambiguity, flesh out requirements, communicate issues, and think holistically without the distraction of a compiler/syntax-highlighter/etc. I think whiteboarding is slightly more about communication than coding and can provide a lot of context in a short amount of time. Of course, not all whiteboarding interviews are equal - I spent plenty of days complaining about certain whiteboarding interviews, and now I'm clearly biased to believe that mine take the good and leave behind [most of] the bad.

Code pairing. Takes ~1hr to understand and modify some piece of code in a meaninful way. (Maybe there are simpler versions - but in an effort to feel more "realistic", I've always focused on changing a requirement to the candidate's code submission). It's more realistic than whiteboarding, but it carries the [real-world] overhead of getting syntax right, finding docs for a specific function, and other surpries that come up (network issues, desktop crashes, editor problems, etc.). I've seen it work well when there are several interviews that focus on very different skills, but inevitbaly after such interview, I've often felt like I had a very narrow view of a candidate.

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

#192

Post by NovelSpinGames » Mon, Jun 22, 2015, 7:17 PM UTC

philbarr wrote: post #75

jdimov9 wrote: post #71

I agree that most complexity in software systems comes from managing state. So here is a simple solution - stop doing it. Stop managing state. Use the right tools for the job. Most mainstream programming languages are ridiculously inadequate for building any production software of any significant complexity without introducing more problems than you are trying to solve. Use a mature functional programming language th…

Here we go again with the "functional programming will solve all your problems" thing. It won't. Every language has it's inadequacies.

Some inadequacies are much bigger than others. The two big ones for me are nulls AKA the billion dollar mistake and mutability by default. I agree that functional programming won't solve all your problems, but it has a lot of very useful features. Some features, like higher order functions, have made their way to more imperative languages. I use higher order functions all the time in my C# programming. And a lot more functional features (or at least F# features), such as tuples, pattern matching, records, and immutable types, are in the C# 7 worklist: https://github.com/dotnet/roslyn/issues/2136

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

#193

Post by krapp » Mon, Jun 22, 2015, 7:19 PM UTC

JustSomeNobody wrote: post #187

cpursley wrote: post #48

Earlier quoted context omitted.

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.

And some of us use Github as a rubbish bin for half-baked projects and hobby code, and not a resume.

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

#194

Post by jeremiep » Mon, Jun 22, 2015, 7:20 PM UTC

trb8 wrote: post #167

jeremiep wrote: post #74

Earlier quoted context omitted.

The abstractions provided by Java and C++ aren't very good compared to those provided by, say, Haskell and Clojure. For the most part, design patterns exist merely to fix the lack of a simpler lambda construct in the language. They more often than not add complexity rather than remove it. The biggest balls of spaghetti code I've ever seen we're always OOP with design patterns. I've seen far more clean C codebases tha…

I would be hesitant of this so easily accepting this view due to selection bias. Java and C++ are often found in huge, legacy, or enterprise oriented code bases. The are plenty of ways to use the abstractions in Java and C++ to write nice code. Just like it is possible to find a Scala or Clojure code base that went crazy with the usage of "cutting edge" features and abstractions in those languages. And at least with…

I completely agree it takes discipline and experience to write clean code in any language.

What I'm saying is that it takes more discipline to cleanly use Java or C++ than it does to use Haskell or Clojure. For the simple reason that most of the abstractions provided by the former languages add to the program's complexity rather than remove it.

There's an excellent explanation by Rich Hickey in Simple Made Easy: http://www.infoq.com/presentations/Simple-Made-Easy

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

#195

Post by HaloZero » Mon, Jun 22, 2015, 7:32 PM UTC

BurningFrog wrote: post #143

msandford wrote: post #7

This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features that would have been impossible on the old code-base. It turned the job from hellish (features were impossible to add) to very nearly boring (there wasn't much to do anymore). So with this newfound freedom I built some machines to automate the data entry and on…

> Sadly there's (seemingly) no way to interview people for this ability I had one interview where the interviewer simply showed me a printed page of code, and asked me to talk about it. I spotted a few problems and debatable constructs, and we had a good 3 minutes discussion. Since at least I spend more time reading code than writing it, that felt like a truer test of my abilities than many of the coding tasks. PS. Y…

I'm curious, how complex was the code. I would love to try this out at some point. Did it fit all in one page?

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

#196

Post by mtviewdave » Mon, Jun 22, 2015, 7:46 PM UTC

aaggarwal wrote: post #185

mtviewdave wrote: post #180

Earlier quoted context omitted.

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…

>But still, there must be one project that the candidate considers his best work, one he/she is proud of, one where he has motivation to do best.

For an experienced developer, that would be a workplace project, which you probably could not see. Indeed, it _should_ be a workplace project; would you hire a professional developer whose best work is their personal project?

But if what you're saying is that the mark of an ideal developer is one who has produced a personal-time product of professional quality, where every checkin is to workplace standards, and has developed the project from conception all the way to release, again all on personal time, then what you're asking for is not a developer who also codes as a hobby, but a developer who (at least part of the time) works two actual jobs. One of which they do for free for portfolio development. I don't find that to be a reasonable expectation, even if it would give employers "important insights".

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

#197

Post by infinite8s » Mon, Jun 22, 2015, 7:48 PM UTC

moron4hire wrote: post #163

infinite8s wrote: post #155

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…

Makes sense. When you said they were in the same space I thought it meant both your ideas had strong overlap.

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

#198

Post by halostatue » Mon, Jun 22, 2015, 7:51 PM UTC

Balgair wrote: post #79

icbat wrote: 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.

My policy for this is that we have a pairing exercise that either: (a) is on sample code that the candidate brought, (b) an open source project with the end-goal being a pull request, or (c) a Make Work exercise. I do not want to have a candidate working on our real code precisely because I do not want to have the charge of unpaid work levelled against us.

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

#199

Post by abc_lisper » Mon, Jun 22, 2015, 7:51 PM UTC

This is always a good idea. Here are some of the things I do

- Establish conventions early; Conventions in managing projects, conventions in code. And stick to those conventions. Be predictable, in the code. Use simple names.

- Protect your interfaces. By this I mean, use a central place like a wiki to document your interfaces, so all involved parties may agree upon. Write unit-tests for interfaces. Use libraries like mockito and hamcrest that make it a breeze.(You would lock your home every time you go out, don't you?)

- I mentioned this in the previous bullet, but write tests. Write lots of them, write tests that document any tricky, magical behavior. Cover all the cases(A boat with one hole is bad as one with two holes). Cover all the invariants, any thing that you notice but didn't mention in the source code. Write tests for the bugs you just fixed.

- If you are developing in Java, please use an IDE. I use Intellij, but Eclipse is good too. It makes refactoring code much easier. Rename fields, pull classes up the hierarchy, create abstract classes, create getters and setters automatically with refactoring tools. I am not against emacs or vi, but it is hard to manage Java's sprawl with them.

One of the best programmers I know writes code like it has been generated with a program. It is boring, dull and looks alike in every direction. Every field and method is documented, it says what its purpose is, and why it is needed. He is very fast(fast for a startup, not your average enterprise), accurate and gets a lot of stuff done without magic.

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

#200

Post by msandford » Mon, Jun 22, 2015, 7:54 PM UTC

aaggarwal wrote: post #185

mtviewdave wrote: post #180

Earlier quoted context omitted.

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…

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

Were I to have such a project that I could show to people, it would be for a company that I had founded and as such despite my having the ability to show it, I would have absolutely no incentive to do so.

Basically if I had EXACTLY everything you purport to want in an employee I would be entirely unmanageable. Someone who has not only the skill and ability to turn out such a project but the motivation to do so on their own time is probably the definition of a founder. And founders are often terrible employees.

So while you're right that it would theoretically be better for candidates to share their codebases with potential employers, in practice I suspect that it rarely happens.