This teapot just happens to be the right size, in the right place, for these tempests.
781 karma · joined May 15, 2009
I, for one, won't try to second-guess your decisions. The Onion has been around for a long (internet) time, and I suspect most of the Web101 suggestions have been considered.
Besides, you guys have left me in stitches too many times for me to be particularly critical. Thanks for existing!
Given that CPython is about Python, whereas IronPython is about Python and the MS environment (libraries, IIS, MSSQL, etc.), it looks like a decent alternative if you like Python, or are just tired of C#.
It would also have the benefit of better tools and the option to use a JOIN or a transaction where it made sense. Of course, you could do the same with MySql, too.
Does it _feel_ fast?
That's probably the most astute observation I've heard this week.
I agree that they should give you better guidance as to your budget before you accept the position.
As for contacting your predecessor, I wouldn't bother. You're not going to get an honest answer out of anybody; everything said about the other will be heavily influenced by the "breakup".
I'll summarize what happened: your predecessor picked a fight, and lost. Leave it at that. The specifics may not be the least bit relevant, won't change what you're going to have to do, and will likely taint your views of your coworkers.
Go in with a clean slate, and make the job your own. Maybe you'll need to pick the same fight. Maybe not. Why worry about it, when you're sure to have plenty of immediate problems.
And again, I would expect better budget guidance before accepting, regardless.
Most places have very reliable backup procedures. Most of those have very poor restore procedures - I'd say about half fail when put to the test.
I would certainly agree that smell-recognition may be more difficult than image-recognition. However, there's been a lot of progress on that front, more than I expected just a few years ago.
The number is probably irrelevant, but the idea is to keep pushing for the deeper meaning (or root cause, in this case). If you can keep your reasoning from being circular ("the sky is blue because it isn't any other color"), you either get the answer, or learn that you don't know enough to get the answer.
Currently, it gets used for more than "deny/allow all" - it is selective. If I have to worry about stuff I don't want indexed being indexed, then I'm going to block all crawling. Yes, I know that wouldn't be easy, but I wouldn't be alone in my sentiment.
Fluency, absolutely. If a programmer is spending a lot of time thinking about typing, instead of "just typing", that's time spent away from the core problem.
While fluency and speed are related, and fluency may lead to or imply speed, the actual rate of typing seems (to me) to be unimportant.
You don't need to "relate", or "understand" other people. You just need to recognize and develop an appreciation for their point of view, even if it doesn't make sense to you.
The best way to do that is to immerse yourself in it. If "people" were a new programming language that you needed to learn, how much would you dedicate to learning it? If it were a language that you would be required to use for the rest of your life, how much would you give to it?
It won't be easy, and it won't come all at once. I assure you, as someone who has gone through all of this, that it is totally worthwhile. Professionally and personally.
BFEA-wise, the technical challenges revolve around the intersections between the various projects - message queues, batch servers, databases, storage (and more storage). Proponents of independent teams tend to dismiss these challenges, resulting in an overall environment that is more expensive to implement and manage. (for example, sure, that obscure OSS project may be _perfect_ for the task, until the one guy that knows it leaves, and you have to pay someone top-dollar to ramp up on it)
To be fair, there's usually a lot of room for improvement, efficiency-wise. To continue to be fair, I don't know that the success rate of small dev shops is any better or worse than the large: there are more failures than successes, and many more "good enough" situations.
Did I miss a link where I could've avoided that.
Good interview, otherwise. Just a PITA to read.
Assuming that the only problem is that they are inexperienced...
On a team of that size, you're not only doing development, you are (or should be) grooming future senior devs. In the enterprise world, on timelines that run 5-10 years, with groups 100+ in number, you have an entire ecosystem to manage.
Also, in groups of that size, you're going to make mistakes in hiring. I've seen the same thing on small teams, where the whole team interviews someone who ends up sucking. With a 95% success rate, with 100 people, you're still talking five screwups.
Breaking things into smaller teams doesn't necessarily get you what you want, either. You end up with a bunch more management, turf wars, and a bunch of other hard-to-deal with crap.
Basically, at the really large scale, it is less about the code, and a lot more about managing people over a long timeline.
There's a natural friction between developers and infrastructure. Developers consume the limited resources which IT has to manage. I've done plenty of both, and basically, both sides are correct. I recommend working on the "other side of the fence" for a little while to anybody in the industry.
Now, if Amazon or someone were to offer a variation of EC2 that did satisfy all the various privacy/data retention laws and regs...
/me scurries off to do some idle research
It had to do with a connection being reset in the space of time between the server checking if the connection was good, and actually using it.
The client could reproduce it at will, and after a little bit of code at home, I could, too. Back at the office, no repro.
It took a lot of back and forth (to put it mildly), but the problem at work was that the network was too slow - the server got the reset with plenty of time to "notice" it, and the crash didn't occur.
Once we set up the repro on its own switch at work, everything failed in the expected manner.
After a few mistakes, here's the tack I've learned to take.
Treat everything you give as a gift. Don't expect _anything_ in return, and say so very clearly. This keeps you from giving more than you would like to, and prevents the recipient from asking for more.
Any kind of loan leaves the door open to additional requests; after all, they're going to pay it all back, so what's a little more? Which leads to resentment if you decline.
Considering it as gift prevents you from going overboard - if a gift is inappropriate (paying off a friend's debts falls here), then don't do it.
In my experience, the best way to give money to your friends isn't for the necessities, but for the luxuries. When I go to a party, I bring plenty of really good booze and/or beer. If we go out to eat, we go to nice places, and I pick up the tab. On trips, I pay the difference between the Motel 6 and the Sheraton (or whatever).
Part of it is couching it all in the right terms. You aren't doing this for them, you're doing it for yourself. I don't like cheap vodka, I like the good stuff. I don't like Motel 6. Then don't bring it up again.
The tone you want to set is that you don't want to share your money, you want to share your experiences. After all, that's how we all became friends to begin with.
ADDENDUM: it is also important to leave openings for your friends to help you, in whatever way they can. Right now, I'm prepping my house for sale, and I've had a stream of friends come over to help me clean and fix things. I could just pay someone, but this way is much more fun.
*edited for poor grammer
While I know that there are a lot of horror stories (and I can tell a few), some of the most productive "programmers" I've ever met used MS Access or Excel.
If you don't consider advanced usage of these applications as a form of programming, then you are illustrating the point: It is not only possible to "dumb down" programming, it is inevitable. So much so that you haven't even noticed it happening.
Where am I now?
Heh. I mentioned that looking for duplicate files is harder than I thought it would be. I'm actually on my third try. The first one was when I thought "I can do this with a script", the second was with .NET, where I aimed bigger, but found not nearly big enough.
So, I've just completed the work on the file crawler, and the next bit is submitting the crawl results to the index. I've done this part before, and I don't expect it to be particularly hard, but I have to find the time for it. After that, something resembling a UI (I am trying to solve a problem), then put the whole thing out there with a big fat "alpha" disclaimer (probably Apache license, since I'm using so much of their stuff).
And that's what I'm doing, and where I'm at.
Hope this helps.
FWIW, that's exactly what I'm working on.
Mr. Manjoo related a story about Firefox, and the crowd cheered. If there was really that much demand for it, then it was a failure on the IT department's part to know that it was wanted, and if they knew that, not at least acknowledging it clearly. There's plenty of good reasons not to upgrade.
What Mr. Manjoo missed is that there are tradeoffs to the freedom to install whatever you want, most of them related to support. A lot of IT policy is driven by how much they have to provide that support. Less money means coarser support - heavily locked down machines, aggressive re-imaging, or similar. Things that don't require a lot of people time.
The confirmation bias that both articles triggered in me, though, was that it clearly showed that in neither case is the IT department and the users communicating.
Good IT is hard, not just because of the technology involved, but because you have to make long term decisions which will permit you to react to users ever-changing needs and wants.
Remember, we're here for them, not the other way around. When I walk into a shop that doesn't live that attitude, I know I'll find a lot of problems.