Live data from Hacker News

Organizing complexity is the most important skill in software development

johndcook.com

211–220 of 286 posts

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

#211

Earlier quoted context omitted.

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.

Other than "virtual reality" with some aspect of "multiplayer", they don't. I'm going after productivity applications. They're going after social networking.

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

#212

Earlier quoted context omitted.

Our main product was developed on a keyboard that was missing a "w". It's not a big deal, though - you can use a for(;;) loop instead of a while loop without hurting performance. And it's easy to just avoid "w" words in the view templates by being clever with word choice. Of course, that's not true at all. But giving someone a defective-but-not-entirely-broken tool can be a clever way of seeing how they work around p…

I'm sorry but I can't help to find this situation ridiculous. Unless you're from a very poor country there is no excuse for not having a working keyboard. I don't know if that was part of the test, but if it was, it's worse than the big blue chip corps asking about the number of piano tuners. Which actually can be valuable at understanding how one reasons about unknown problems/areas. About the server being slow, wel…

I have been forced to work with really old computers connected to as old research hardware. At some point it is probably more economical to let someone figure out the interface and solder something together with an Arduino or similar so we can start using a new computer. But that point is never now. Until then we have this old chain of hardware just to get the data from the old machine via 5 1/4 floppy disks.

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

#213
Since so many people prioritize getting then task done than writing organized/beautiful code more often then not we get code that isn't organized properly.

Thus, as a result: Interpreting complexity is by far the most important skill in software development. More-so then organizing complexity.

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

#214

Earlier quoted context omitted.

I got fired from a job because I had done this and they couldn't figure out how to keep me billable after that. Well, I got fired because I would "show up late" and "leave early" because there was nothing else for me to do (even though I was actually pulling a full 40 hours, they were expecting 60 out of people). They could have given me more work, put me on new projects, etc., like I kept asking to be done, but inst…

Great takeaway. Debt tends to make 'good little workers'. Stay free my friends!

I think P.T. Barnum wrote the prototypical "Self-help: finance/entrepreneurship" book in "The Art of Money Getting: Or, Golden Rules for Making Money" [0]. A lot of it sounds like the stuff you hear getting hammered to death on motivational TED talks. It's a pretty short book and he doesn't go into too much exposition on a lot of the issues he addresses, with the exception of debt. He probably spends half of the already short book on talking about the evils of debt, especially debt put into things that aren't assets. It's not the debt that is the problem, it's the mindset you have to be in to take the debt, the mindset that the debt puts you in, and the mindset of the type of person that continues to use debt, especially destructively. There are some closely related issues with spending money, which tie in nicely.

It's an interesting read. This book was written in 1880, and if not for the dated writing style, would fit right in to the modern day self-help genre. It really helps underscore the idea that there's "nothing new under the sun."

[0] http://www.gutenberg.org/files/8581/8581-h/8581-h.htm

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

#215
post #135

Earlier quoted context omitted.

that assumes the candidate has an online repo somewhere. I think this is quite a discriminating practice - what if i don't do public projects?

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.

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

#216
And Metalevel complexity. I may have been able to craft beautiful code, but I sensed chaos in the way I operate and manages my own resources / tools. I've seen people being organized at many, if not all, layers, solving problem and solving how to help solving problems. Witnessing that makes me feel calm and envious at the same time.

ps: it's also reminiscent of recursion, dogfooding etc.

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

#217
post #49

the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity Agreed. very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else Agreed, BUT... In order to organize, sooner or later, you will have to get clever (with tricky data structures or algorithms). How I have always built something big and/or com…

Still too many lines of code! Being organised has nothing to do with fewer lines of code. A 10 line script can be disorganised and a million LoC app can be well organised. What makes code organised is things not being tangled up together - having well encapsulated logical modules that do one thing (or a set of related things), with a well designed API to get each bit to work with the other bits. I've found that the m…

An insight I've had here is to write the code the same way I would have as if I'd done red green refactor tdd, but then add only the essential unit tests at the end. Works very well and is much much faster, but obviously you'd have to have done a lot of red green refactor tdd previously in your career or on side projects to really know what testable code looked like. Reading Working With Legacy Code by Michael Feathers may be a shortcut to that knowledge as well.

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

#219

Earlier quoted context omitted.

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

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

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

#220

I agree that it is an important skill in engineering to recognize when the complexity got too high - At that point you need to take a step back (or several steps back) and find a different path to the solution - Sometimes that means throwing away large amounts of code. It's about acknowledging (and correcting) small mistakes to make sure that they don't pile up into a giant, disastrous one. Another thing I learned is…

Agreed. From my experience breaking things down into smaller pieces helps so much with initial development speed, future code change speed, and testability.
Post reply on HN