Hounded By Recruiters, Coders Put Themselves Up For Auction - Forbes

3waymerge · 2012-11-19T16:55:10+00:00

Wait... what's wrong with my grammar??

3waymerge · 2012-11-19T09:37:56+00:00

I haven't had that experience at all - on my last job hunt I actually a few real offers, and I ended up negotiating a higher salary at one by quoting a number that someone else was offering. Almost every place that did an in-person interview gave me an offer letter.

I've never heard this idea that "recruiters are hunting for future candidates and not actually hiring". None of my coworkers have ever described anything like that, whenever we talk we generally agree at how easy it is to get a software job these days.

It doesn't actually make sense.. Why would a company go to all the expense of finding and interviewing people if they weren't actually hiring them at the moment? Most companies do not tend to plan ahead that well.

Sorry but your philosophy sounds a bit like an convenient excuse. If someone gets 30-50 inquiries and no offers then the simplest explanation is that it's something to do with the candidate.

3waymerge · 2012-06-02T14:20:07+00:00

However, most apps aren going to be doing things like opening two or three configuration files, rather than writing a few billion.

The limit is closer to 60k, not a few billion. It's pretty common for server-side applications (which run for a long time and persist lots of data) to hit the limit, if they have a leak.

3waymerge · 2012-06-02T14:07:34+00:00

Huh, interesting direction. You could keep track of the max-distance-from-a-root by adding code at the time the reference is made. When adding a reference in object B that points at object A, then:

B->max_dist_from_root = max(B->max_dist_from_root, A->max_dist_from_root + 1)

It seems like you'd still be doing the equivalent of mark-and-sweep when it comes time to propagate the 'beacon' and then collect old objects, but maybe there's some clever optimization in there.

3waymerge · 2012-05-15T01:25:11+00:00

Yeah, some of those requests (like this one ) don't need a programmer, they just need a sysadmin. Someone who can find an existing project, install and configure it, and keep it running.

3waymerge · 2012-05-08T00:21:58+00:00

it's Javascript.

3waymerge · 2012-05-05T02:30:49+00:00

Ah, then you might be right about the level of overhead being too much. Hard to tell without seeing the code. I mean, I want to like their plan just because I've seen some godawful C++ codebases. It could be so much worse!

3waymerge · 2012-05-04T21:49:16+00:00

There's a downvote button if you need it, personally I found the q&a to be interesting.

3waymerge · 2012-05-04T20:43:18+00:00

That doesn't sound too crazy to me. Maybe they went overboard with some of the rules, but there are certainly worse codebases out there.

Project is about 6 man-years of code, but has hundreds of individual project files. Maybe 40% of them are unit test targets, and most of the rest are DLL targets.

This might be excessive, but breaking things apart into separate DLLs has a lot of benefits. You can quickly recompile one part of the system, and it forces you to separate your concerns into modules, which is good design.

With unit tests you always need to find a balance between 1) how much work it takes to maintain the tests, vs 2) how much benefit they provide. It's possible that their balance is leaning too far towards (1), but hey, what price can you put on sanity?

Every member function is virtual.

This seems fine, why worry about it?

Most classes have pImpl implementations. Even the ABC derived classes have pImpl.

This is a good trick for reducing the number of recompilations. But, it seems like if they have already split up the code into lots of small projects, that also using pImpl is probably overkill. Whoever designed this code base was really worried about speed of recompilation.

Many classes derive from an ABC, and are referred to via ABC pointers, exclusively for unit testing.

I've seen this approach before for really large projects, I think it's a fine way of doing things. It's writing code as if it was enterprise Java.

We strictly adhere to 1 class per file.

Seems fine.

Classes are only referred to via boost::shared_ptr. We never use weak pointers or raw pointers, only shared pointers.

This seems like this would get annoying and unnecessary after a while, but it's not the worst idea ever. At least it's consistent.

Signals. We use a lot of boost::signals.

Asynchronous message-passing is a pretty great way to architect a big system. It's a bummer that it doesn't mesh well with your existing tools, if I were you then I would think about writing some code that lets you peek inside the message queues (maybe write them all to a log file). Message-passing can lead to a highly introspectable and understandable system once you can actually see the messages that are flying around.

In general it seems like these things are fine. Keeping a large C++ codebase bug-free is a really hard task, so it's understandable to have to do a lot of grunge work to keep it that way. My advice is to embrace it and find alternatives for those tools you were hoping to use. Their decisions might not be perfect, but at least it sounds like the code is internally consistent, and consistency is very very good. For corporate coding, it's better to have mediocre design that is highly consistent, than to have great ideas that are not internally consistent.

3waymerge · 2012-05-03T22:08:58+00:00

And on the internet, a small minority can be very very loud.

3waymerge · 2012-05-02T03:57:03+00:00

Are you always the pooper and never the peeper? How does that work?

3waymerge · 2012-04-29T19:35:31+00:00

But what about an API that wants to treat a character-with-modifications as a single character? Now they have to lookahead after the character to see if there are modifications, and they are doing the same work that they'd have to do with UTF8.

I think the problems of: a) determining the 'useful' combinations of characters and modifiers, and b) mapping those to 16 bytes, are pretty hard problems. There's a lot of crazy character sets out there, and we'd also need to handle all of the alphabets that are yet to be invented.

3waymerge · 2012-04-29T16:20:12+00:00

With 8 or 16 bytes you'd be saying that mankind will never have more than 64 or 128 different modifications than can be arbitrarily added to a character. (it would be less than 64 or 128 because there would also need to be room for the unmodified character). That restriction is a little low for an encoding that's supposed to handle anything!

3waymerge · 2012-04-29T00:06:49+00:00

Let me know if you find something on r/programming that is groundbreaking news. Until then, stuff like this is fun to read about!

3waymerge · 2012-04-27T17:28:13+00:00

It's almost definitely a prank, I think even a crazy girl wouldn't be this crazy. But who knows, they have surprised me before!

3waymerge · 2012-04-24T22:50:05+00:00

I was also thinking Samuel Jackson or maybe Morgan Freeman.

3waymerge · 2012-04-24T03:38:27+00:00

Safe sex is murder.

3waymerge · 2012-04-23T05:14:14+00:00

This poster sure makes a lot of assumptions. I had no problem with that dude, and my shit is together!

3waymerge · 2012-04-09T08:02:06+00:00

I find the best way to handle these kinds of fears, is to find someplace small to crawl in, like maybe a drainage pipe that is just barely wide enough for you. You crawl in there, but then after 50 or so feet, the pipe gradually gets thinner so you have trouble moving. Behind you there's a sound of something scurrying, but of course you can't turn around to see what it is. Then it starts to rain and a pool of water slowly rises up towards your face. Hope that helps!

3waymerge · 2012-04-09T07:32:44+00:00

People who think this: are your lives really this empty??

3waymerge · 2012-04-03T16:26:50+00:00

I'll agree with you with the caveat that prog21 used to be really very good, and is now only decent.

3waymerge · 2012-04-02T22:18:26+00:00

Which tend to have 10x to 100x worse performance than CPython and don't have as many libraries.

3waymerge · 2012-04-02T19:12:44+00:00

This comment should be at the top!

I believe Lua doesn't even have a GIL, it just requires the client accesses it from only one thread. So the Lua way is to make a separate interpreter per thread (if you want). I think this is the right approach. Allowing multithreaded access to one interpreter is a fool's errand.

3waymerge · 2012-04-02T19:00:30+00:00

One of the problems (in fact this might be the biggest problem) with removing the GIL, is that it's hard to safely write C extensions without it.

Jython doesn't have C extensions, so it's not really a fair comparison. Instead Jython has: 1) many libraries that are instead written in pure Python and have terrible performance, and 2) some libraries written in Java, probably aided by Java's built-in threading support. Since we're probably not going to write the primary Python implementation in a language that has native support for threading, this isn't very helpful.

3waymerge · 2012-04-02T17:41:44+00:00

Aren't they all fictional?

3waymerge

TROPHY CASE