Text only mirror:
http://webcache.googleusercontent.com/search?q=cache:http://...
Organizing complexity is the most important skill in software development
81–90 of 286 posts
Re: Organizing complexity is the most important skill in software development
#82Organization is the hardest part for me personally in getting better as a developer. How to build a structure that is easy to change and extend. Any tips where to find good books or online sources?
Same here. I only have 2 years of experience, but right now my opinion is that this is not something you learn in a book (for the moment). You can learn how to create clean, readable methods and classes with a book (1). You can learn how to refactor old methods and classes with a book (2). You can learn how to organize a small team to allow fast iterations with many books. But building a project lasting more than a f…
My personal experience is that I had to maintain a set of applications I wrote for a company. The same application had to be used repeatedly (3-5 times) a year because it supported a specific business processes.
It was mundane work, but did it teach me how to organize because it made the pain of disorganized code very real.
That one hack comes back to haunt you several times a year.
I was lucky that this was one of the first things I had learned as a developer out of school. It was a little different because the projects were small enough to be solo, but it was humbling because all of the mistakes were my own.
Re: Organizing complexity is the most important skill in software development
#83the 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…
I find that the older I grow as a programmer the less I enjoy cleverness. There's never a good enough reason to use clever algorithms over boring ones. In fact, most of the refactors I did over the past year was to 'undo' cleverness (thankfully those programmers are no longer working here!)
In terms of performance you sometimes need to do less conventional things, but that's precisely where documenting WHY you're doing it that way is so important.
The small bits of performance you're going to get isn't worth the maintenance hell it's going to cause.
Re: Organizing complexity is the most important skill in software development
#84Earlier quoted context omitted.
I find diplomacy a highly important skill as a developer as well. Strangely I feel I've become worse at it as the years go on.
One of the problems I hit was that I would get really grumpy when particular things were asked for. Once I learnt to think about why I was getting grumpy, and vocalize the actual problem it was easier. e.g. A client said to me recently could clicking the blog link open a new window? When I started programming I'd have said "Yes! I can do that!". Then after a few years I'd have got grumpy about it and said something p…
Related to what you are saying, I read somewhere, many years ago, that the best thing to do in cases where you feel like being grumpy or dismissing something that was asked for was to, instead, ask 'why'.
The reasoning is that sometimes what the client is asking is his best guess as meeting a need he has. By asking why, chances are you'll get to the actual need and, oftentimes, find a better solution where both the client and you are happy.
Over the years as a grumpy developer, this piece of advice has served me wonderfully well.
Re: Organizing complexity is the most important skill in software development
#85There is a term for it. It's called managing scope. I'm surprised the article didn't mention this.
Re: Organizing complexity is the most important skill in software development
#86Earlier quoted context omitted.
> I wish there was a job title for "good all-arounder with knowledge of the state of the art in a role with substantial self-direction", but I think that's probably "founder" or something. Or "owner of a very small business" maybe? That's the way I am drifting. I just can't seem to get in gear on my own. :(
Why's that? I've been thinking about starting my own side company. It is a lot of work!
In my case, it's the "lot of work" issue that is the problem. It's really easy for me to ignore the work I don't understand very well (marketing) or don't enjoy very much (which is largely a function of not understanding very well) for raw programming.
I have a couple of friends doing a startup in the same space in which I'm writing some software, and their software is nowhere near as far along as mine, yet I don't have anywhere near the "business development" that they do. I'm not there because it's too much work for one person and I've focused on the tech. Their tech isn't that great because it's too much work for one person and they've focused on the biz.
Aaaaah, I just don't know. They're pretty inexperienced, mostly just straight out of college. I'd like to find one person who is as passionate and experienced about business development as I am about software development. Instead, I mostly get contacts from guys who've worked in government offices all their lives, looking for a free programmer to boss around on their "1 in a million idea".
Re: Organizing complexity is the most important skill in software development
#87Earlier 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.
Spending 45 minutes working on "a contrived piece of legacy code" with an employee competent enough to evaluate your effort doesn't sound to me like "doing work" for the employer. I get what you're saying, though... I think if the evaluator were incompetent and you were solving an important problem for them (things that would be pretty obvious), it would be an awful interview. But hey, that's 45 minutes well spent if it shows you for sure that you wouldn't want to work there.
Re: Organizing complexity is the most important skill in software development
#88Earlier 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…
How'd you do it if the keyboard wasn't working?
Re: Organizing complexity is the most important skill in software development
#89page not found
Re: Organizing complexity is the most important skill in software development
#90Earlier 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.
Pairing makes this seem less egregious to me, even if the company is getting some value from the process. In a traditional interview, both you and the interviewer would be spending the same amount of time, and arguably learning less about each other.
Asking for some work to be done off site before an initial on site interview, where the potential employer is getting something of value, would be a much bigger red flag to me, personally.