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

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

#251

Post by overgard » Tue, Jun 23, 2015, 12:59 AM UTC

vijayr wrote: post #55

ska wrote: post #41

Earlier quoted context omitted.

> Sadly there's (seemingly) no way to interview people for this ability I think there is. Show the candidate some bad code. Not WTF code, but something you wouldn't be proud of but is realistic. Bonus points if you're comfortable enough to pull this out of your own production system. Ask the candidate about adding some functionality, but be clear that cleanup and refactoring changes are fine (even encouraged). The co…

This happened to me once. I went for an an interview at a huge real estate company. They had a chat with me for exactly five minutes, then gave me a computer (an old one, with keyboard not working properly) and some legacy code. I wasn't asked to fix it, but I was asked to make a small change and given half hour for it. That code had no documentation and no comments. Then 5 more mins to explain what I understood abou…

You know, interviews ideally go both ways. If a company was not willing to provide me with working equipment, I would likely decline any offer they might make. Not because I need the best of the best hardware or anything, but because it would be a huge red flag that they don't value the position or the people that fill it.

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

#252

Post by eropple » Tue, Jun 23, 2015, 1:42 AM UTC

__z wrote: post #215

eropple wrote: post #160

Earlier quoted context omitted.

Generally speaking, I preferentially hire developers with public projects--though I do not just pick one at random and ask for one they're particularly proud of. I think open source development is virtuous and is something that I want to promote and encourage; in the process, I get what I think is a better view into how somebody works. If you don't do public projects, then you start a few steps behind the other candi…

You are probably going to miss hiring a real lot of excellent candidates with that attitude. > I think open source development is virtuous and is something that I want to promote and encourage Then pay them for it.

Only in the weirdly defensive world of Hacker News does preferring people who contribute to open source software imply throwing out resumes without it, does it imply "missing out" on those people. Of course I consider resumes without open source work. It would be stupid to not do so. But I will look first at those with a publicly auditable track record. Is that a surprise? I look, earlier in the list, at people who've worked at a number of large firms with strong technical teams, too. They shrink the error bars on hiring.

Though, even if it didn't mean I was getting a view into how they actually work, I'm okay with preferring public-minded people who give things back and make the world a better place through it. I try very hard to live by the motto "pay it forward" and I find it to be rewarding and pleasant to work with those who do likewise.

> Then pay them for it.

My last two employers did exactly that. Should I need to hire directly for my consulting adventures, I'll do it there, too. I mean, this reply makes no sense to me: why would I not?

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

#253

Post by ademarre » Tue, Jun 23, 2015, 1:45 AM UTC

> Organizing complexity is the most important skill in software development

I agree with this profoundly. Unfortunately, complexity is in the eye of the beholder. When comparing solutions to a problem, different developers will not always agree on which is the least complex.

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

#254

Post by rsuelzer » Tue, Jun 23, 2015, 1:48 AM UTC

This times 1000! The really sad thing is that 9.9 out of 10 technical interviews are all about how many Algo's you know. Even if your job will never require actually implementing a single one.

These interviewers do not seem to care at all about the actual process of writing and refactoring code, or what your finished products actually look like.

I know plenty of programmers who can write highly optimized code, but do so in a way where it is completely impossible to maintain.

It's especially heightened when you are given a problem such as "validate if this uses valid brackets, and you have 10 minutes." When under time constraints to solve what is basically an algorithm 99% of programmers are not going write their best code or write code in the way they would normally write code.

If you are using lots of algo's on your programming interviews, I suggest you take a step back and determine if those skills are actually what you want to be testing for in this job. Odds are that it is NOT algo's. Give your interviewer some really sloppy code to refactor into something beautiful. Give them a few hours to work on it, watch how they put the pieces together.

If your position isn't going to require someone to write advanced algorithms on daily basis, testing for them only cuts out a huge swath of potential talent. I also think it probably leads to less diversity in your work place, which is a bad thing.

A Web Developer will never need to solve the towers of Hanoi problem, but they will need to write clean code that can be maintained by others.

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

#255

Post by edpichler » Tue, Jun 23, 2015, 1:49 AM UTC

Our humans are "comparing machines". For this reason we tend to valuate people that solve problems more than the ones who never create them. This is really bad.

Also, in business, if someone is really good administrator, it seems he never does nothing.

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

#256

Post by rsuelzer » Tue, Jun 23, 2015, 1:50 AM UTC

ska wrote: post #41

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 think there is. Show the candidate some bad code. Not WTF code, but something you wouldn't be proud of but is realistic. Bonus points if you're comfortable enough to pull this out of your own production system. Ask the candidate about adding some functionality, but be clear that cleanup and refactoring changes are fine (even encouraged). The co…

I agree. There are tons of ways to test for this. Write a simple library that doesn't use any good design principles and have your candidate spend some time refactoring it. You can even use the same library multiple times. Heck, have your senior engineers also do this, so that you can get a good baseline for what an ideal candidate should come up with.

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

#257

Post by TrophyWipes » Tue, Jun 23, 2015, 1:58 AM UTC

rsuelzer wrote: post #254

This times 1000! The really sad thing is that 9.9 out of 10 technical interviews are all about how many Algo's you know. Even if your job will never require actually implementing a single one. These interviewers do not seem to care at all about the actual process of writing and refactoring code, or what your finished products actually look like. I know plenty of programmers who can write highly optimized code, but do…

Interviewee*

And as someone who is about to graduate computer science, your rant makes me hopeful :)

I am much better at refactoring and finding patterns than memorizing algorithms and other things (mainly because they are relatively easy to look up). Do you suggest that I try to strike a specific balance between practicing dealing with complexity, optimizing and making code readable, versus actually trying to memorize and implement certain algorithms for learning's sake?

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

#258

Post by azundo » Tue, Jun 23, 2015, 1:59 AM UTC

wpietri wrote: post #173

BurningFrog wrote: post #143

Earlier quoted context omitted.

> 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 had an interview recently where we did something similar and it was awesome. They had picked an especially good example: the code was small enough that it didn't take long, but it has a variety of sorts of badness, from coding errors to bad names to bad method grouping to logical errors. I'm definitely stealing this trick.

I wrote one of these for my work as well. Definitely our go-to for getting a sense of how well people can understand others' code and how they think about data modeling/complexity. A very small initial page of code can go a long way.

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

#259

Post by rsuelzer » Tue, Jun 23, 2015, 2:11 AM UTC

TrophyWipes wrote: post #257

rsuelzer wrote: post #254

This times 1000! The really sad thing is that 9.9 out of 10 technical interviews are all about how many Algo's you know. Even if your job will never require actually implementing a single one. These interviewers do not seem to care at all about the actual process of writing and refactoring code, or what your finished products actually look like. I know plenty of programmers who can write highly optimized code, but do…

Interviewee* And as someone who is about to graduate computer science, your rant makes me hopeful :) I am much better at refactoring and finding patterns than memorizing algorithms and other things (mainly because they are relatively easy to look up). Do you suggest that I try to strike a specific balance between practicing dealing with complexity, optimizing and making code readable, versus actually trying to memori…

I'm not a computer science grad, and it puts me at a huge disadvantage simply because I never had any formal training about algorithms. And my day job is to write testable, well-designed production quality code. I don't get to spend a lot of time rewriting algorithms, which as you note, can be easily looked up. The fact is that as a full-stack developer I can count with zero fingers the amount of times I've had to use an self-made algorithm in a production system.

That being said, I do force myself to practice algorithms thru various coding challenges only because I know that this is the specific skill that will land you a job. Which is a shame.

That is not to say that there are not positions that really do require this specific skill, but the vast majority of development positions don't and yet nearly every employer tests their candidates as if their success depends upon their ability to solve an algo in under 5 minutes, instead of their ability to write a good library.

It's a disservice to those of us who do not have CS degrees and have learned to code by spending a great deal of our time writing code.

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

#260

Post by nostrademons » Tue, Jun 23, 2015, 2:28 AM UTC

juliangregorian wrote: post #219

kazinator wrote: post #189

Earlier quoted context omitted.

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

Forgive my ignorance, but are there any extant examples of garbage collectors (real GC, not reference counting) that don't stop the world?

So when you say "real GC, not reference counting", you have to understand that tracing GC and reference counting are duals, and every concurrent collector is going to be some hybrid of the two [1].

But there are a number of algorithms that most people would probably consider "real GC" that don't stop the world. Modern Java GCs use the train algorithm [2], which bounds pause times to some arbitrarily-sized constant. Erlang per-process heaps [3] also give good soft-real-time characteristics.

It is theoretically possible to run the whole GC in a background thread (eg. while a GUI is idle). Both the JVM and the CLR have options for this [4][5], but they're only useful for workloads with large pause times (eg. GUI apps, lightly-loaded servers) and so aren't enabled by default.

[1] http://researcher.watson.ibm.com/researcher/files/us-bacon/B...

[2] http://www.ssw.uni-linz.ac.at/General/Staff/TW/Wuerthinger05...

[3] http://prog21.dadgum.com/16.html

[4] http://www.oracle.com/technetwork/java/javase/gc-tuning-6-14...

[5] https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110)....