Europilot: A toolkit for Euro Truck Simulator to develop self-driving algorithms - <AUTHOR> https://github.com/marshq/europilot <comment><USER2> I'm glad I saw this link, I was looking into building a solution based on parts of the ChosunTruck codebase[1], but Europilot seems more flexible since it's built as a "bridge" rather than a fully fledged self-driving solution.

[1] [https://github.com/bethesirius/ChosunTruck](https://github.com/bethesirius/ChosunTruck)

<comment><USER3> Exactly the same for me. I had ChosunTruck bookmarked but Europilot looks much nicer at first glance.

Another related thing that I wanted to check out is this: [https://github.com/Microsoft/AirSim](https://github.com/Microsoft/AirSim) although that only gives you the sim and you have to do the machine learning part completely yourself.

</comment></comment><comment><USER4> Here's a YouTube playlist where a guy made a self-driving vehicle in GTA V using Python.

[https://youtu.be/ks4MPfMq8aQ](https://youtu.be/ks4MPfMq8aQ)

<comment><USER2> He also streams the self driving vehicle 24/7 on Twitch, it's quite amusing to watch, every now and then the autonomous vehicle causes an accident and ends up being chased by the Police LOL [https://www.twitch.tv/sentdex](https://www.twitch.tv/sentdex)

It was also very interesting in the early days because you could see the agent getting much better day after day.

<comment><USER5> haha, I switched just in time to see it meekly surrender to the police.

It looks like it still has a lot of improving to do to manage basic stuff like not accelerating into oncoming vehicles, but it's quite neat to see that its mastered the art of stealing another vehicle after writing its own off, which isn't something your average self driving neural network gets trained on.

</comment></comment></comment><comment><USER6> There is quite a lot of interest in a self driving car simulator. I wonder if we could use Kickstarter to raise some money to get the game maker to add simulated radar, lidar, and cameras. You should be able to customize the position of these sensors.

<comment><USER7> A self-driving car simulator would be interesting and maybe there's some chance at making it open source?

A self-driving sim, to be realistic, is also going to need realistic traffic simulation. I helped bring traffic modeling to the computer age, that is what my business did.

When asked for a quick description, I like to say that I built the greatest traffic simulator on the planet. Of course, I'm heavily biased. Eventually, we could even render some of that data into graphics.

Yeah, so it probably wasn't a thrilling simulator with broad appeal and it required a whole lot of compute power and huge data sets. Either way, it probably would have resulted in a good, albeit very large and computationally expensive, engine for a traffic simulating game.

I signed a non-compete that lasts for life. It may not actually be legally binding, but I feel ethically bound to it. But, a game would not be competing in that space - less so if it were FOSS.

What I'm trying to say is that I'd be interested in such a project, though I'd want to seek legal council. I can program a bit, but I eventually hired professionals to do that on my behalf. Let's just say that you probably don't want me submitting actual code, but I can almost certainly help with the math involved.

I'm just spitballing, really. If someone wants to do something like this, I'd be willing to take a peek and see if there were a way to contribute. I sold and retired, but I still hold great fondness for the art. Modeling traffic isn't easy, it's a chaotic system and you never really know the initial starting state.

So, if you decide to go FOSS, let me know. If it is in C, or C++, I might even remember enough to lend a hand coding, though that's probably a horrible idea. My entire code base was rewritten by actual competent people and programmers were different back then. They were quite comfortable expressing their frustrations with working on my existing code. They were, shall we say, very eager to share their knowledge - sometimes with various levels of vulgarity.

Anyhow, to model traffic at a high level of accuracy, even things like the reflectivity of lane markings will have a quantifiable impact on traffic. You can observe the effect by monitoring traffic before and after lane markings are painted. Traffic is even influenced by the fonts used in signage. Lots of seemingly small things can be accounted for and the models made more accurate.

I'd love to lend a hand, assuming it isn't going to get me sued.

<comment><USER8> So, which was the traffic simulator you worked on? I've always been fascinated by traffic and traffic modelling, read books [1], seen articles where they use cellular automata, psychology, discrete events, etc etc.

[1] [https://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307...](https://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307277194/ref=sr_1_1?s=books&ie=UTF8&qid=1505601119&sr=1-1&keywords=traffic)

<comment><USER7> I'd prefer to not disclose the specific names for reasons of a modicum of privacy. It's long since sold, anyhow.

But, yes! It's absolutely amazing what goes into modeling traffic as accurately as possible. When we expanded to model pedestrian traffic as well, we even went so far as to build a mock store.

It's fascinating to see how small changes can influence traffic and alter the throughput. Simple things, like frequency of signage has a large impact. There are also regional differences where whole regions will, as an average, drive very differently.

You can run all the models, collect all the data, and someone will still get drunk and reverse the wrong way on a one way street. You'll never get perfect predictions and so there are constant changes being made. That kept it interesting.

What I worked on was all proprietary. It'd be interesting to see an open source project in this arena.

</comment></comment></comment></comment><comment><USER9> An obvious disadvantage is that you don't have LIDAR inputs. I guess it would be rather difficult to hack ETS such that it generates them.

<comment><USER10> I'm not sure. LIDAR is just about the simplest thing to render in a simulation: a relatively small number of ray-scene intersections.

<comment><USER11> Simulating lidar returns in a way that has noise similar to real devices is difficult

<comment><USER12> Indeed. There are tons of things that happen in real world lidar. For ex, if object is too close it may not detect. When you are going at high speed, returned light ray may arrive early or late giving bit of error. Also, think about multiple reflections, noise, cone size and so on.

</comment></comment></comment></comment><comment><USER13> How does training the NN using a limited frame per second affect the training accuracy? Why not go higher or lower than the one you are using?

<comment><USER14> In terms of capturing the screen input for training, the fps is capped at 10 fps. This is following the number suggested in NVIDIA's paper[1], which cautions against overfitting. The program captures faster when the steering angle gets larger, because it suggests that curvy road is ahead, which are the more challenging scenarios for the program.

In terms of testing, the max fps is determined by the performance of the GPU and the complexity of the model. I couldn't find any definitive studies done on the matter, but anywhere from 10-30 fps seems to work OK.

[1] [https://arxiv.org/abs/1604.07316](https://arxiv.org/abs/1604.07316)

<comment><USER15> Add a RNN with a 10-frames history on top of NVidia's model and you get the winning Udacity challenge entry (mentioned on selfdrivingcars.mit.edu). I assume you also programmed this model during Udacity's Self-driving car nanodegree.

</comment></comment></comment><comment><USER16> Does this publish CAN bus events ?

I was looking into similar solutions to capture CAN bus events for telematics usecase.

<comment><USER17> It's a video game so there aren't any CAN bus events.

<comment><USER18> That sounds like an interesting idea for a mod though...

</comment></comment></comment><comment><USER19> Do you guys know if it's possible to programmatically alter ETS environment? (such as weather, brightness, traffic, etc). Thinking of using the simulator to generate augmented data.

<comment><USER20> Most likely. All those effects are already built-in, and it looks like there's a pretty comprehensive modding community.

There might not be an API callable from outside the app, though...

</comment></comment><comment><USER21> This is brilliant! I built a similar system on top of Flight Simulator for an internship. So useful!

</comment><comment><USER9> > With europilot, you can capture the game screen input, and programmatically > control the truck inside the simulator.

Can't this be easily generalized to _any_ game?

<comment><USER22> This is really cool. Consider introducing this concept to an FPS game, at what point do you consider it to be an aimbot?

<comment><USER23> That is exactly what aimbots are. Sometimes you can make bots easier by using an addon system to export information(WoW), or themes to color your targets (CS), but at the root you read the screen and control the mouse.

<comment><USER24> No. At root you read and write the game's memory. Most aimbots just read the memory to get locations and call the game's own methods to adjust the aim from their injected dll. Barely any actually bother reading the screen, it's horribly inefficient and limited.

<comment><USER23> I've used and written a ton of bots that read the screen, sometimes it's the best option.

<comment><USER24> Ditto, but with manipulating the game directly either through memory reading/writing, dll injection or packet sniffing.

Can you give some examples where screen reading was more effective?</comment></comment></comment></comment></comment></comment>


Why Is America Dotted with Giant, Concrete Arrows? - <AUTHOR> http://www.citylab.com/work/2015/02/why-is-america-dotted-with-giant-concrete-arrows/385472

<comment><USER2> Parts of America are also dotted with giant concrete Christmas-tree icons, but the aviation involved with those is a little less benign.

[http://en.wikipedia.org/wiki/Christmas_tree_(aviation)](http://en.wikipedia.org/wiki/Christmas_tree_\(aviation\))

</comment><comment><USER3> [https://news.ycombinator.com/item?id=6453401](https://news.ycombinator.com/item?id=6453401)

Previous discussion

</comment><comment><USER4> I like that in old Superman comics he would use one of these giant arrows as a key to the fortress of solitude. Only someone with super strength could gain entry.

At the time I first read a reprint of an old Superman with the aircraft arrow they had probably been obsolete for decades, which like English police boxes just seems to make them more magical.</comment>


34% of Marketers don't believe they can measure their social media marketing ROI - <AUTHOR> https://www.mayple.com/blog/measure-social-media-marketing-roi <comment><USER2> Yeah, good intro. The problem is that most companies still use the rather meaningless "last click attribution" method and see that social media does not yield results while most people convert through search.

Without discovery on social media the whole customer journey you ideally measure will not even start though. The actual search for the product that comes at the end won't happen that way either.</comment>


Why You Should Hire an Old Programmer - <AUTHOR> https://joshondesign.com/2017/07/02/hire_old_programmer <comment><USER2> When talking with young programmers I too often think "well, you are doing that wrong, been there, done that". They don't want to listen. A couple of months later they notice that the gray beard ones were right. From a company perspective, that's just too late, as the money loss is not recoverable.

There is nothing wrong with being a young one with no experience. There is so much wrong when a company has only a bunch of young programmers and no experienced one who lead them.

<comment><USER3> Conversely I find that a number of the old(er) programmers I've worked with are incredibly stubborn and bigoted. They refuse to see anything from another persons perspective _especially_ if that person is young. As well refusing to keep up with 'modern' technologies and paradigms because "that's not how I'm used to doing it". It's a lot of the "I've been round the block a few times I know what I'm doing" bullshit attitude.

But obviously that's a generalisation. Just like your comment is.

<comment><USER4> Yup. I've seen 55+ year old programmers write what was essentially a message queue persisted in a database table, processed by a cron job. We frequently had problems with duplicate processing of messages, due to multiple cron jobs running at once.

I've personally argued against a key-value store schema in SQL Server and was in favor of a flat-table design. In our case, there were records of different 'types', and each type may have a number of fields always be null. Looking back, I'd probably do something like this:

       Entity
           common attribute 1
           common attribute 2
           etc

       Entity_Type1
           entity_id fk references Entity,
           type1_attribute 1,
           etc

He was certain that the flat-table design would take up more space since it would 'have to store every attribute every time'. Most of these were varchars, so (looking back) that was straight up false. Not only that, but in a key- value schema you have to store the name of the 'column' (key)... every time. I was unable to articulate the harms of key-value schemas when it comes to queryability...even though our existing system was filled to the brim with 'unions' due to a key-value schema. I lost this argument.

Each of these developers refused to use git, in favor of visual source safe. I know.

All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.

I've lost count of the times I've been steamrolled in discussions. I'm not sure if it's my age or if I'm just lacking that much socially. When you lose an argument over key-value schemas of all things it makes you really question if you know what you're doing...

<comment><USER5> >All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.

I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument.

It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in. I use the database for what it was made for, and only what it was made for: to persist and retrieve data. Anything else should be in the code.

Also, key/value schemas are terrible and slow, but sometimes they're the only way to get the dynamic nature of what you are doing. The best compromise I've seen of that is to have the values you _know_ are going to be used a lot by groups/customers flat, then have the key/value schema for anything oddball.

I guess the moral of the story is old/young doesn't really matter. It's know / don't know what you are doing. I guess it boils down to thinking about what you are doing. Key value is very dynamic but I'll bet it's slow. Do we need fast more than dynamic? Is there a compromise that will satisfy both requirements? Many people don't think that deeply and just want to get it finished.

When I was young, the dot bomb was the "great filter." After that, there were a lot more people who knew what they were doing because they survived. It sucked though, I don't recommend it.

<comment><USER6> > I'm and old programmer and I've been arguing against business logic in SPs > since SQL Server 6.5 and have been losing ever since. That's not an > old/young argument.

> It's because vendors (in this case MS) recommend putting code in SPs. I > suspect it has to do with lock-in.

If i recall correctly, back in the dark ages of Classic ASP and SQL Server 6.5, database stored procedures was the only feasible way of implementing a reasonably performing web application.

<comment><USER5> No, we had middleware back then. It was ugly text over sockets, or worse, DCOM, but it worked. That was more ISAPI than classic ASP. If nothing else, we could create a queue table in a database and have a Windows Service pick it up.

<comment><USER6> Ah DCOM, fun times.

Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005), "precompiling" queries in stored procedures was recommended for performance reasons. It was even asked on hiring interviews, at least to me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I think programmers should reframe the problem. If cognitive decline is real, why would anyone hire anybody over 40? Yet there are plenty managers, politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40.

If you want a culture where people retire at 40, go for it. But please don't pretend that programmers are "special" in that the decline in their skills is worse than decline in skills of anybody else.

<comment><USER8> programmers actually need to think sometimes. the jobs mentioned are more routine and rely on soft skills and experience a lot. I do not mean any disrespect by that. mathematicians are also best when they are young, but unlike programmers work in academia and get to teach until retirement, whereas programmers get replaced.

<comment><USER7> > mathematicians are also best when they are young

This guy springs to mind: [https://en.wikipedia.org/wiki/Laszlo_Babai](https://en.wikipedia.org/wiki/Laszlo_Babai)

Because, yeah, programmers and mathematicians don't actually need any experience, they can just think everything up on the spot!

I also wonder how you imagine that other professions gain their experience, if they don't need to think.

<comment><USER8> it is a historical fact that most of the best mathematicians make their famous discoveries when they are younger than 30. if you have studied the subject, you'd know this, so i assume you just dislike these facts and argue for the sake of it.

<comment><USER9> I would question whether this is actually true. Stats on Field medalists have to be taken with a grain of salt, given that it is awarded at 40 years top in the first place

<comment><USER8> That is pretty limited information. Talk to a good professor. he will gladly admit that his mind is not as nimble as it was once. maybe he will say things like hes glad he can still keep up and do research. mine told me this in front of an entire class just to drive the point home that 'the time is now'.

<comment><USER9> I have been doing mathematics up until a couple of postdocs - and based on first hand experience I think that the story of young mathematicians is mostly a myth.

Maybe people in their 60s were not at the center of research, but I would say that the field was dominated by people in their 40s (certainly not by 20-something).

I cited the Fields medal, because their artificial limitation on age is one of the first things that comes to mind when talking about the subject

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> The most frustrating thing about being an older programmer is watching organizations make the same mistakes over and over again. Yeah, sure, you might want to hire an older guy because he has experience with the intangible project stuff. But only if you're planning to _listen_ to him. I feel like Bill Murray's character in _Groundhog Day_ :

Me: We need to create our security architecture in the beginning. It's always harder to add when we have a bunch of functionality to work around.

Management: But we don't have time. We promised these features by January 1st. Don't worry about security yet - the initial version won't have critical business or customer data.

Me: We'll never have time. Once the users get ahold of this we'll be buried under requests for new features and critical bug fixes. Particularly since the only way we have to test it is to have people poke at it in a browser.

Management: Adding automated testing would take too much time.

Me: ...

<comment><USER11> I'm in my early 30s, so frequently called an older programmer and I've heard a lot of, "we don't have time".

What I've been waking up to is that projects that estimate realistic budgets and time scales don't get funded. Everyone underbids knowing that the company/customer will continue to fund and extend deadlines for project after sinking so much effort into a buggy prototype, until the realistic estimate is reached and the product actually reflects all the "hidden"/"discovered" requirements (i.e. foreseen but not in the bid) including security, integration and test efforts.

What's weird is that everyone, customers included, seems to be in on this.

<comment><USER12> What you describe is often the scenario of do-everything consulting sweat shop building tailored or customized solution from scratch based on a single customer requirements. Management often lacks business vision and technological path. Front sales and techical people are randomly assigned and switched between ad-hoc projects with varying industry domains and poor communication chanels.

I think only debt slave or masochist stay in such places for longer. Age doesn't matter.

I would rather look for more focused software product companies with stable teams.

</comment></comment></comment><comment><USER13> How do older programmers deal with coding interviews from companies like facebook / google? i feel like those advantage people who just finished their algorithms class, or have time to practice specifically for it.

<comment><USER14> _How do older programmers deal with coding interviews from companies like facebook / google?_

Badly. The unfortunate truth is that if you've hit 40+ without having built up enough expertise and contacts to bypass those types of interviews then finding a programming job is going to be really hard.

<comment><USER15> > bypass those types of interviews

Can you elaborate a bit? I hear this all the time (get the job through contacts and _networking_ not by applying and interviewing) but nobody will go into step-by-step detail about how one actually can manage to "bypass" a company's interview process.

Company: "Thanks for your interest in working here. Your resume and application are impressive, and you have great references! Obviously you are skilled, so forget about having to interview. How's $180K plus benefits sound, and can you start in a week?"

I've been in tech for close to 20 years and that scenario just sounds absurd to me.

<comment><USER14> _step-by-step detail about how one actually can manage to "bypass" a company's interview process._

Networks and reputation. Get a former boss/colleague that knows you (and who has ideally ended up in a position some of trust/responsibility) to recommend you to his boss. If someone the boss trust tells him that you have the exact combination of expertise they're looking for and that you're the person they need then everything goes a lot smoother.

That's how I got my current job. A former colleague (who'd ended up in a management position) called me out of the blue, invited me out to lunch and straight up asked me if I'd be interested in a new job. I still had to interview, but it felt like much more of a formality.

You can also just ask people. Keep a list of people you've work with that you trust/respect and that you believe trust and respect your skills and just keep in touch with them once every 6 month or so. Let them know that you are open to switching jobs if something interesting comes along and ask them to keep you mind.

Another way is to become a 'name' in your field. If yours is one of a handful of names that always comes up when people are talking about who in town is really good at X then chances are people will start seeking you out.

<comment><USER15> Not sure that counts as "bypassing the interview" but thank you for your thoughts! This seems like normal networking 101, get your foot in the door by knowing someone there.

However, I've seen people claim, here on HN and in other forums, that they have received offers (not just opportunities to interview), sight otherwise unseen, from companies based purely on their own reputation and/or references. That's what seems unbelievable to me.

<comment><USER14> It's not bypassing the whole interview, but it is bypassing the "coding interview" gauntlet which is what seems causes the most anguish. If you're there on a strong recommendation from a trusted colleague then the interview becomes as much the company trying to convince you to work there as it is you trying to convince them to hire you.

</comment></comment></comment></comment></comment></comment><comment><USER16> This guy assumes that old programmers are not super enthusiast and hard worker but they have experience, while young ones are enthusiast, hard worker and motivated but they know nothing, that's not a very rigorous way to prove something ...

All that is just nonsense !

</comment><comment><USER17> I would _never_ hire this candidate, based on seeing this.

So - the author says that he has "developed some good communication skills". Great! Moving on, let's look at his linkedin page. Quotes from past jobs: "even after our idiot (now ex) CEO canceled the platform.", "wonky JavaEE stuff.".

So, as a hiring manager, from this post + linkedin, I now know that this guy: 1) can reach large audiences, 2) trashes past jobs and colleagues publicly. And thus, I would be terrified of hiring the author, as there seems a 50% chance that this will end with my employers being trashed in the same way. That's just not worth it.

OP: Come on, give yourself the chance to be hired by removing that from linkedin.

<comment><USER18> This is indeed basic psychology [1]: talking bad about other people reflects poorly on _you_, not just the people you're talking about.

[https://en.wikipedia.org/wiki/Emotional_contagion](https://en.wikipedia.org/wiki/Emotional_contagion)

</comment></comment><comment><USER19> I've worked with old programmers who are great and old programmers who suck. Most of the points in the article are obviously wrong.

"Anyone who is still a programmer in their 40s has to have developed some good communication skills." "Old programmers are dabblers." "Old programmers have judgement." "We can pick up any new language because we've used so many over the years."

I've met old programmers who are counter examples to all these points.

A steelmanned version of the article would argue why older coders are more likely to have these skills than young coders. It also needs to talk about the average difference in ability relative to the variance in each group. If old coders are on average 0.1 standard deviations better than young coders you should focus on hiring the good old or young coders. If old coders are on average 1.5 standard deviations better than young coders you should just focus on hiring the good old coders and exceptional young coders.

</comment><comment><USER20> What a ridiculous assumption. It is not about age! I've seen both young and old horrible coders. Of course you can have a slight advantage from experience if your'e older, but the quality of that experience remains relative to the person in question. You might have 10 years of experience doing things the wrong way!

Growing older doesn't make you a 10x dev, just as it won't make an average musician a superstar.

</comment><comment><USER21> If age is not a good indicator of someone being a bad hire, then it can't be a good indicator of someone being a good hire either.

</comment><comment><USER22> To be honest, as a middle aged folk I find it impossible to relate with ping pong culture and open space offices. On the other hand, cubicles here are too often signal of brick & mortar ways to intend business, which ultimately means losing value. That's why I think older folks like me should really get into contracting or external consulting. As an alternative, do with finding a job at utilities or other non-cyclic ventures, they always seem eager to listen to juvenile-but-not-disruptive folks to innovate just a bit, not too much, not too fast.

</comment><comment><USER23> I know more this year than I did a year ago.

I will know more next year than I do today.

This will never stop.

<comment><USER24> My grandmother knows less today than she did ten years ago.

<comment> david-gpu We are talking of ordinary folks in their forties and fifties, not senescent folks in nursing homes.

<comment><USER25> Then we shouldn't say "never".

</comment></comment></comment></comment><comment><USER26> I don't disagree with anything stated here, but how much of this actually is a function of age?

I feel like a young programmer could aquire all of these traits also, because they're less about age and more about being able to learn from experiences. You can choose to have more experiences to become the kind of person the article talks about.

Or is this a survivorship bias thing? The old programmers are more likely to be this way because the people who would be old programmers who are not this way aren't programmers anymore?

<comment><USER27> Well I'm not sure if you're young or just playing devil's advocate, but a young person often feels that way.

The whole knowledge * intellect idea that someone else here mentioned is far too reductive. You can be a ridiculously smart person who has read white papers and coding books, learned all about discrete math and project management, worked on as many projects as you could, and still not touch the maturity of an older software developer. Why?

Experience doesn't begin and end with topics directly surrounding your vocation; your whole life contributes to it.

As you age, you get to know yourself better. Old people have made far more decisions in their life than a young person has: lots of good ones, and lots of bad ones. You know your decision making process and its flaws. You remember what it feels like to reap the rewards of a good decision, and even more intensely, you remember the sting of a bad decision. You know, from experience, what decisions you should make, what ones you shouldn't make, and any confounding variables.

You also start to understand those same patterns in the human and organizational behavior of people you live and work with. You start to get an intuitive understanding of the kinds of mistakes various kinds of people make in various kinds of situations. There's a reason that older people– often ones without a ton of domain knowledge– are generally the ones making big decisions in a mature company, while the younger people are working out the details.

For example, the couple decades that I spent as a bouncer in clubs might not help me see if I'm making a bad coding choice per se, but it vastly increased my understanding of group dynamics, ego, negotiation, how to mitigate the damage of having to make snap decisions with a whole lot of consequences, how to respond when someone tries to intimidate me or make me feel uncomfortable, deescalating pointless arguments, and even starting a fight when one really needs to be started. (the worn-smooth restraint and fighting techniques have much less utility in the office... so far) Before I gained that experience, I'd have no way to have known it would proved useful in a software development career. I'm sure many parents, people who have coached sports teams, people who have experienced the death of an industry, or even people that have gone through messy divorces can all point to things they've taken away from those experiences which have vastly improved their judgement and maturity.

And it's not just the soft skills which are improved by this understanding. Being more mature means you write more mature code. I look at code I wrote 15 years ago and shudder. It's not that I have a better understanding of the mechanics of Perl or C now than I did then, but my sense of logic has been refined, I'm more patient, and I have a better sense of where to put in extra effort and where to cut corners.

When you're young, you're still mostly figuring out what you're capable of, but you don't have a very good sense of what your limitations are. When you get older, you've got a pretty good sense of what you can do, and a much better sense of how to keep yourself and everybody else out of trouble by avoiding what you can't do. The problem is, lack of experience is generally pretty opaque to the people who lack it.

¯\\_(ツ)_/¯

<comment><USER28> "lack of experience is generally pretty opaque to the people who lack it"

Agree! this is a succinct description of a eng management problem. However, it can be mitigated by hiring coachable, trainable (and mature) people. Interestingly, we've had great luck hiring from programming bootcamps; programmers who lack programming experience but have other work experience & who are eager and able to learn quickly, & usually come with some level of intellectual curiosity (as opposed to entitlement).

<comment><USER27> Totally. I've also had good luck with people coming out of programming boot camps. _In my current line of dev work,_ I'll take someone who's really eager to learn new things and jump on tasks over someone who can confidently invert a binary tree on a whiteboard.

</comment></comment></comment></comment><comment><USER29> I'm 58, live in the country (UK) and found a programming job almost exactly suited to my skill set (Pascal mainly-i.e. Delphi along with C# plus a few years of C, C++). Add in 5 years of 6502/Z80 assembly (games in the 80s), two years of Ada. The last three years was creating a mobile app in C#/Xamarin. Plus lots of php, html, SQL.

To stand out from other candidates I prepared a 7 minute screen cast (using Camtasia which I bought a couple of years back) showing off programs I'd written and briefly mentioning programming aspects that made each program different. I uploaded it to Dropbox, emailed the link to the recruitment agent who forwarded it on. I got the job after two interviews and have just completed my first week. I was lucky, round here there aren't that many programmers and most jobs are for C#/ASP.NET MVC websites. It's just a 30 minute drive away.

The job interviews included an online IQ test (not a problem), a logic test which was not my finest hour (4PM on a Friday is the worst time for me!) and a 10 minute stand up presentation on the subject of my choice. "A trip to an Arctic Isle."

</comment><comment><USER30> I will risk a quote by C.S.Lewis:

"Experience: that most brutal of teachers. But you learn, my God do you learn."

</comment><comment><USER31> Hiring is more than the job tasks: there's work culture, politics and external factors. At least here in Mexico, the people usually are very political (we call them 'grillos'): they tend to form groups, brain wash other employees and use the law to their advantage, because in Mexico, the employer has to prove almost everything in case there's a work dispute.

And that's another reason to consider: yes, there are young people that has these traits, but mostly it comes from experience (or as we say here, 'colmillo').

The other big factor is the old saying that old dogs don't learn new tricks, so it's difficult to guide them towards the company vision, and it's worse when they have a boss that could be their son.

Those are my experiences based on Mexico, I know there are better places in the world with different mindsets, I just wanted to include my thoughts on this topic.

</comment><comment><USER32> If you're trying to get hired please always include your location in your communications so that you don't get rejected out of hand for not appearing to be 'close' and/or waste peoples time.

</comment><comment><USER33> Be old dev doesn't mean that you know how to write code. I worked with devs with twenty years of experience, and I love it, and I learnt A LOT from them.

On the other hand, I worked with old devs too, and they did a lot of spaghetti code, they didn't make a module and a lot of things are weird for them. Like async/await/yield.

I think that it's not an old programmer, it's about the attitude that they had during his professional career and the attitude that they have now. With a lot of experience and the right attitude, I agree, it's a perk in the team!

</comment><comment><USER34> as an old programmer I think it would be better if the author said 'I know this, because I hired one.'

<comment><USER23> Even better. 'I tried to hire one but someone else made a more compeitive offer.'

</comment></comment><comment><USER35> 2 reasons why you will OR won't be hired as an old programmer:

1- "programmer" is the entry level in a software/hardware company. Rising stars move up in the ranks over the years and take more responsibilities. Manager, sr. manager, director, VP, etc. still a programmer at 40?

2- If you're still programmer at 40, you might really like it! We're looking for programmers and need age/exp diversity in our group. You are rare my friend and valuable.

<comment><USER36> A programmer with 20 years of experience is definitely worth more than a programmer with 2 years of experience. But not that much more. A skilled architect with 8-10 years of experience will beat a programmer with 25 or 30 years experience every day in terms of ongoing business value, and will command a much higher salary (15-20% or more).

So yes, you can absolutely have a professionally rewarding, lucrative career as a 40-50 year old programmer, but you'll earn more money by moving over to the business side, simply because you can more easily show a direct line between your actions and business revenue.

<comment><USER5> Job titles are meaningless. When I say 20 year programmer, it's what you would call an architect, senior engineer, whatever. The programmer being someone who doesn't do any design is a foreign concept to me and should find another career. Any architect that doesn't write at least the skeleton code is the same. All levels of that career needs to involve design and implementation of that design.

<comment><USER36> Every company I've worked at with 2 or more developers has acknowledged a difference between a developer responsible for high level architecture and technical ownership of a system(s) who happens to program some of that system as well, and a developer responsible for programming parts of that system who happens to architect smaller self-contained pieces of it.

Architecting a class or small single-use library is a subset of the skill required to architect a distributed system, a large multi-tenant application, or some other non-closed system.

Whether you want them to have the same job title or not is I think orthogonal to the fact that they are very different jobs.

<comment><USER5> I think you are trying to differentiate between a programmer with 20 years experience and what you call an architect by using titles. Like I said titles are meaningless. A programmer with 20 years experience who can't design a large system isn't a very good programmer. An architect who can't design a large system isn't a very good programmer either.

I think we are arguing the same thing, we're just stuck on the semantics of titles. I guess let me put it this way, do you know people who have the title of programmer who are way better at building systems than a guy with the title of architect? Of course. Some companies don't even use the title of architect. That certainly doesn't mean no one in the shop can design a large system. It's not the title, it's the ability, and titles are a horrible way to discern ability.

>A programmer with 20 years of experience is definitely worth more than a programmer with 2 years of experience. But not that much more.

This is what I took issue with. A (good) programmer with 20 years experience is capable of designing large scale systems, which is much more valuable than a programmer with 2 years experience. Maybe it's just my bias.

When I first heard the term "architect," I asked, "what is that?" and the reply was, "someone who designs large systems but doesn't code." I thought to myself "well that's dumb." FWIW, I've had the title of "architect" at various companies since 2008 and I've always coded at least the skeleton of my designs. I mean how else do you know if you're right? When I switched companies in 2010, the new company didn't have the title "architect," so I was just a "senior engineer," until we got acquired. I regained the title "architect" because I made X amount of money. Like I said, meaningless. As a side note, I think coders calling themselves engineers is also incorrect. Engineering is a specific discipline that actually has meaning. It's like Dr. Dre. It sounds good, but I sure ain't going to see him for a rash.

</comment></comment></comment></comment></comment><comment><USER37> Consider smartness as "what you can do with what you know," while experience is "what you know"\--then, what follows is that having more experience makes up for not being as clever.

        Able to make good choices = Intellect * Experience

Moreover, employers can _try_ to assess intelligence with whiteboard interviews...but the easier factor to evaluate is experience. It's right there on the resume!

<comment><USER38> Yeah, except 10 years at certain companies could teach you less than 6months to 1 year at one company that's actually doing it right.

I hesitate to try and prescribe an answer for the "how employers should find good employees" question, because it's so difficult, but I imagine the ideal hiring process would:

\- Allow candidates a choice on how they want to be tested (take home thing, online code test, whiteboard, whatever else)

\- Ask better questions at the abstraction level that would show experience. For example, if you want to know whether someone has experience, give them an architectural diagram (or process diagram) of your current project/workflow/whatever, and ask them how they would improve it (and if they've ever been through the steps they suggest themselves/how they would roll it out).

There was an excellent post on HN a while back detailing what a specific company (whose job is doing interviews, I can't for the life of me remember what company it was), learned from doing thousands and thousands of interviews.

Also I'm not super good at math, but in the equation you posted wouldn't the intellect variable be pretty much equal to experience, and you could make up for one with the other? Or maybe you're implying that the scales for each multiplier are different (like intelligence might only go 1 to 10 but experience might go 1-100?)? I agree with what you're getting at, basically that someone who has seen lot but isn't as clever will often make better choices than someone that's very clever, but completely green.

<comment><USER37> > Yeah, except 10 years at certain companies could teach you less than 6months > to 1 year at one company that's actually doing it right.

Is it common for programmers that have been on a job to not realize the ways in which their software sucks? Knowing what to avoid and the consequences of doing things wrong is an important factor of experience; additionally, maintaining a bad system gives insight into mitigating problems.

That said, I do agree that experience isn't just a passive function of time (as in "interest earned"). Instead, it's more like a landscape that needs to be explored (and to your point, some companies will allow a programmer to explore more productive areas).

> ...the equation you posted wouldn't the intellect variable be pretty much > equal to experience, and you could make up for one with the other?

I suppose the answer to your question would depend on just how much variance you place on intellect. Is it:

\- 0.0 (rock) to 1.0 (cleverest human on earth)

\- 0.0 (rock) to 1.0 (cleverest intelligence across time and space)

Either way, I wouldn't take the equation too seriously--it was just a model to show a trend :/

</comment></comment></comment><comment><USER39> Somewhat related: is oldgeekjobs.com still going? I can't tell from looking at the posts if it's really active.

</comment><comment><USER40> Time does not translate directly to experience, not all experience is equal, and one thing old programmers should know about more than anything else is their personal biases.

I agree with the point- I'm getting older, too- but the reasoning is not strong.

</comment><comment><USER41> In Polish the title "senior developer" is usually translated into "starszy programista"; the adjective "starszy" means literally "older". So, I ask everybody to call me "old programmer". :)

</comment><comment><USER42> Thank you. 56 years old, still writing code. I enjoy working with young programmers, they bring energy and ideas to my projects and keep me from getting stale and stuck.

</comment><comment><USER43> Oh shit, I may have just committed a truly heinous sin, as a "senior developer", by posting this to the company channel.

Ah well, lesson learned. Don't do it, youngsters!

</comment><comment><USER44> You might want to add to the list that you are required to by law if they are equally qualified.

</comment><comment><USER45> Is this post not promoting age discrimination?

Isn't age discrimination illegal?

Why would discriminating against younger people be any more fair or legal than against against older?

I expect discriminating by amount of relevant experience is fair, but that's not the same as age.

<comment><USER46> > I expect discriminating by amount of relevant experience is fair, but that's > not the same as age.

As someone who started coding at age 9, I agree. :-)

It's not about hiring someone in their 40s per se, but rather about recognizing the value of 20 years' experience. Age alone doesn't impart wisdom.

</comment></comment><comment><USER47> I like it. Of course, I'm an older programmer. But still.

<comment><USER36> "I am in favor of discrimination as long as I am not the one discriminated against."

</comment></comment><comment><USER48> Reason to hire a young programmer based on the confession from CTO: we like college grads because we can drive them hard and pay them minimal salaries. The only thing is they burn out pretty quickly. And yes they also lamented the quality of their software and how releases were buggy and delayed. Not sure they saw a connection there...

To attract the candidates they optimized non-salary benefits they thought college kids would like such sports tickets, beer nights etc.

The bottom line is companies know exactly what they are doing and just officially claim some culture fit thing.

Same with hiring women, minorities,etc.

Even with open space offices. They say it's because they want people to collaborate but more often than not they want to save money and monitor people to see if the are "working".

<comment><USER49> > Not sure they saw a connection there...

In my experience, they try not to see the connection. If you try to show it, they'll listen for a bit and then rationalize. If you keep at it you'll begin to see irritation and even aggression.

That a fair number of CTOs have a decent technical background doesn't seem to help much, somehow. I've had this confirmed personally when I got together with a coworker from almost 20 ago who had moved into management. He struggled to keep experienced people because they moved for more money, because they were paying below market value. If I suggest something like paying more, he considers it and then some weeks later I find he's still struggling to figure out a way to keep people, having changed nothing of consequence.

It's my pet theory that (almost all) management _wants_ programming/IT to be a commodity and are willing to pretend that it is, to their detriment. They _demand_ that it be a commodity.

<comment><USER50> I also have that theory, and it's not a stretch since the act of business is to commoditize everything. I especially saw it in the IT consulting business.

</comment></comment></comment><comment><USER51> s/old/experienced

</comment><comment><USER52> Being sweet-talked into raping the world for other peoples awesome profits comes easier when you're 20. The real problem is the messed up priorities of most companies these days; older coders are more likely to call bullshit and demand a fair share of the cake.

</comment><comment><USER53> The problem with Old Programmers, is not their work. Thats solid. Its the fact that they have mortgages, pensions, health issues, etc. This costs employers money. And employers HATE giving money because they feel like since you are getting a meager salary they are already doing you a giant favor.

Its a management cultural issue, not an older programmer issue really.

</comment><comment><USER53> I think, outside of Hollywood. The Tech industry in general is one of the most ageist.

</comment><comment><USER54> didn't read the article, clearly just self promotion.

</comment><comment><USER55> the article is interesting yet based. Most notably, it's clearly written by an old programmer.

<comment><USER56> So clearly that the author explicitly states that he is one: "I know this, because I am one."

</comment></comment><comment><USER57> For hire: [https://www.linkedin.com/in/tvaughan](https://www.linkedin.com/in/tvaughan)

</comment><comment><USER58> To add a dissenting view, ideally I want more seasoned developers, so older is better. However, I still want to hire the right developers. I have worked with some older/experienced developers who were deficient in various ways, including one who had no concept of separation of concerns or testing code.

I think this goes to the mindset that it is always important to try to prove your skills by example.

</comment><comment><USER59> If an attorney were building an age discrimination case against a person (or entity, per jacquesm below) involved in the rejection of a younger candidate, posts like this are among the evidence I suspect would be used to point to a discriminatory mindset. That said, I'm not a lawyer.

If someone were to be making hiring decisions, posts like this discovered during the course of casual googling would oblige the person with a robust basis not to hire. Heck, at least one firm on my CV has instructed me to regard discriminatory language involving suspect classification, age included, as grounds to reject.

<comment><USER32> (1) You don't make legal cases against people involved in a hiring rejection, you make a case against a company.

(2) If you are making hiring decisions the appearance of random blog posts should not and will not give you any legal basis not to hire. Legality is encoded in the law, not in blogposts, especially not in blogposts by random passers by. If you were using this as a reason not to hire the person writing the blog post then you _might_ get some mileage out of it but it could also easily backfire.

<comment><USER59> > (1) You don't make legal cases against people involved in a hiring > rejection, you make a case against a company.

Entirely true. In my defense, I'm not a lawyer. Technically also in my defense: the United States has a bad habit of calling corporations people.

> (2) If you are making hiring decisions the appearance of random blog posts > should not and will not give you any legal basis not to hire. Legality is > encoded in the law, not in blogposts, especially not in blogposts by random > passers by. If you were using this as a reason not to hire the person > writing the blog post then you might get some mileage out of it but it could > also easily backfire.

This may be true in the Netherlands, but in many states in the US, quite a number of things can be used as grounds to not hire, _with the notable exception of_ anything involving suspect classification ([https://en.wikipedia.org/wiki/Suspect_classification](https://en.wikipedia.org/wiki/Suspect_classification)). _My understanding_ is that if someone is likely to cause the firm to be responsible for illegal conduct e.g. age discrimination, for many firms, that's a sufficient basis not to hire.

I'd love to be corrected, though.

<comment><USER32> > if someone is likely to cause the firm to be responsible for illegal conduct

HR policies are what takes care of that, if an individual is able to make the company engage in illegal behavior you have bigger problems in the oversight department. Hiring comes with a bunch of rules, this person should not be able to transcend those rules by their lonesome.

<comment><USER59> We're not at all in disagreement, but even after an enforcement action is taken within the firm, if the illegal act has already taken place, you'll still find lawyers willing to go after the firm.

Policies don't physically prohibit certain conduct; they merely provide a framework of consequences to discourage it. That's also why policies exist on when not to hire someone: to minimize the risk of the new hire acting in violation of policies.</comment></comment></comment></comment></comment>


Time Travel Debugging - <AUTHOR> https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview <comment><USER2> I'm the dev lead for WinDbg and the windows debugging platform, and I'm a former dev working on time travel debugging (I wrote the cpu emulation for the project). Happy to answer any questions that anyone has.

Since I'm "posting too fast", let me put my answers here for now:

qod: Right now you can attach TTD to a process after initialization (or any point in time prior to the repro), but you can't trace starting from a breakpoint. We'd love to add that functionality though, so I'm sure you'll see it in a future version of the tool.

Glad you like the new WinDbg! It's been very polarizing (which you can see just reading the comments on this post!), so it's good to hear the positive feedback sometimes :)

We've got a ton of plans to make debugging even faster and more effective in WinDbg, so hopefully we'll win more people over as we make our tools easier to use and more powerful.

<comment><USER3> First I would just like to say how impressed I am with the new WinDbg and TTD, this is fantastic work and a huge improvement on the existing debugging tools.

My question is: if I want to start taking a TTD trace after hitting a particular breakpoint in WinDbg, can this be done with the current tooling? Use case would be if there is a large amount of initialization code that doesn't need to be traced because the bug or crash is known to occur at a later stage in the program.

<comment><USER2> Right now you can attach TTD to a process after initialization (or any point in time prior to the repro), but you can't trace starting from a breakpoint. We'd love to add that functionality though, so I'm sure you'll see it in a future version of the tool.

Glad you like the new WinDbg! It's been very polarizing (which you can see just reading the comments on this post!), so it's good to hear the positive feedback sometimes :)

We've got a ton of plans to make debugging even faster and more effective in WinDbg, so hopefully we'll win more people over as we make our tools easier to use and more powerful.

</comment></comment></comment><comment><USER4> There is also undodb[0] and gdb supports reversing[1]. There is also the rr[2] project from Mozilla. All of those support Linux.

I also recently discovered WDD[3] (which is for Windows) as well.

[0]: [https://undo.io/](https://undo.io/)

[1]: [https://www.gnu.org/software/gdb/news/reversible.html](https://www.gnu.org/software/gdb/news/reversible.html)

[2]: [http://rr-project.org/](http://rr-project.org/)

[3]: [https://github.com/ipkn/wdd](https://github.com/ipkn/wdd)

<comment><USER2> I believe all of those projects are based on single-core debugging. Restricting the trace to a single core is one way of introducing determinism in the process as a way of allowing replay later. Microsoft time travel debugging is a multi-core technology, which allows you to capture interactions between threads in multi-threaded processes.

Edit: Since I'm still "posting too fast", let me respond here to clarify. Both rr and undodbg support multiple threads, but do not record them simultaneously. They restrict execution to a single core. That's what I mean by recording interactions between threads. For instance, if you have shared memory between processes, that won't work with rr/undodb generally (although I know at least rr can work around this by recording both processes).

I'm not saying one is intrinsically better than the other since there are tradeoffs with both approaches. There is a high constant overhead for recording all cores, but it does have the advantage of scaling well to large numbers of cores.

<comment><USER5> Yes, there is definitely a significant tradeoff here. If you're recording something like Exchange Server having true multi-core execution is a big deal. If you're recording a web browser it's not as important, because most things are still gated on the UI thread. Hopefully y'all can get the constant factor overhead for recording down further over time.

With rr and Firefox we found that with sufficiently pathological scheduling we can eventually tease out many races and other bad thread interactions. This became rr's "chaos mode". I think the biggest drawback of not having true multi-core support in rr today is simply the performance hit that a parallel program will take during recording.

</comment></comment></comment><comment><USER6> Here's a review from the Mozilla folks: [http://robert.ocallahan.org/2017/10/thoughts-on- microsofts-t...](http://robert.ocallahan.org/2017/10/thoughts-on-microsofts- time-travel.html)

</comment><comment><USER7> Here is a recent CppCon video: [https://www.youtube.com/watch?time_continue=3389&v=l1YJTg_A9...](https://www.youtube.com/watch?time_continue=3389&v=l1YJTg_A914)

I'm an escalation engineer at Microsoft, and we have been using this for many, many years to solve complex customer cases. Having it go public is a pretty big deal for us.

</comment><comment><USER8> For more than two decades now, I've been using the limited availability of reversible debugging as an example of just how dysfunctional software engineering is as a field. The shoemaker's family's tattered feet.

Reversible debugging been around for six decades (eg EXDAMS on Multics), been generally practical for two or three, been available in gdb for one, and now, finally, here we are. It's taken two bloody human generations to get this close to widely deploying TTD.

So yay. Maybe I can now retire TTD as an example of glacial progress. There's no shortage of others. Sigh.

<comment><USER9> As far as I can tell EXDAMS was never implemented. The RAND EXDAMS memo is more of a thought experiment than anything else.

Getting reverse-execution debugging to work adequately at scale is difficult. gdb's approach doesn't scale at all. I dispute that reversible debugging has been "generally practical for two or three decades"; as far as I know the first practical products were UndoDB and VMWare.

<comment><USER8> > As far as I can tell EXDAMS was never implemented. The RAND EXDAMS memo is > more of a thought experiment than anything else.

The memo[1] mentions

> Since EXDAMS is currently being debugged and is not operational, no > performance statistics are available. [p12]

Suggesting implementation was attempted, though perhaps not successfully?

[1] "EXDAMS: extendable debugging and monitoring system" Memo RM-5772-ARPA APRIL 1969 [http://www.dtic.mil/get-tr- doc/pdf?AD=AD0686373](http://www.dtic.mil/get-tr-doc/pdf?AD=AD0686373)

</comment></comment></comment><comment><USER10> We at VMware had this working and released in 2008. We supported windows and Linux. We even supported things like network applications that had lots of outside state. It was called replay debugging and besides Mozilla, few used it. Sadly it was killed when workstation 8.0 came out.

<comment><USER11> _" Sadly it was killed when workstation 8.0 came out."_

What ever happened to the intellctual property for that? Any chance it could be open sourced?

<comment><USER10> Internal politics.

</comment></comment></comment><comment><USER12> Very cool stuff! Microsoft also developed a TTD system for JavaScript/Node.js: [https://www.microsoft.com/en-us/research/publication/time- tr...](https://www.microsoft.com/en-us/research/publication/time-travel- debugging-javascriptnode-js/)

At LogRocket ([https://logrocket.com](https://logrocket.com)) we're building a TTD of sorts for recording production users in your web app. While we can't replay exact code, we can get you most of the way there with DOM recording/logs/network waterfall.

</comment><comment><USER13> Oh my god they redesigned WinDbg with a Microsoft Office UI lookalike starter kit including ribbons. And at least one of the screenshots showed JavaScript.

So many fingers crossed hoping they don't ruin this indispensable basic tool. Every platform needs to have a no-nonsense debugger that doesn't fall over immediately when it has no symbols and source. WinDbg (was?) that.

<comment><USER14> I like the 90s UI of old windbg too. Maybe stick to cdb.exe to avoid bells and whistles.

</comment></comment><comment><USER15> Looks very nifty. Is this being developed for Windows only?

</comment><comment><USER16> Mozilla has a similar tool, check it out:

[https://github.com/mozilla/rr](https://github.com/mozilla/rr)

</comment><comment><USER17> This is cool stuff to see in the world of C++. It's great to see language communities feed off each other and drive innovation like this.

<comment><USER18> I think it has been in gdb before Swift.

<comment><USER19> Yes: [https://www.gnu.org/s/gdb/news/reversible.html](https://www.gnu.org/s/gdb/news/reversible.html)

This has approximately nothing to do with C++ or even "language communities".

<comment><USER17> I can't speak for Microsoft itself, but wouldn't the effort to implement a production-ready time-traveling debugging system (as explained here by SteveJS) be at least somewhat influenced by the growing popularity of time- travel debugging in other languages?

<comment><USER20> What other languages got timetravel first? The biggest I've heard is rr from 2014, which is for native code or basically C/C++.

<comment><USER17> One language that has popularized it in very recent years is Elm. It's mentioned everywhere.

</comment></comment></comment></comment></comment></comment><comment><USER21> Reminds me of Qira. [http://qira.me/](http://qira.me/)

</comment><comment><USER22> Just waiting for the rust/lisp squad to come along and tell us that we wouldn't need all this if we just joined them.

<comment><USER9> I'm a notorious Rust fan and also the lead author of rr :-).

</comment></comment><comment><USER19> _TTD is efficient and works to add as little as possible overhead as it captures code execution in trace files._

...and then in the table below the screenshot...

 _Large overhead at record time. May collect more data that is needed. Data files can become large._

Based on past experiences with debugging using tracepoints etc., I'm more inclined to believe the latter.

Also, as a side-note, the "more modern visuals" of "WinDbg Preview" look horrible. It's a debugger, not a toy for the barely-computer-literate. Those who want the "friendly experience" will use Visual Studio instead, which amusingly enough continues to have menus instead of the disgusting ribbons as of the latest 2017 version. The screenshot also shows _two_ lines of slightly- misaligned "Command" "Memory" "Source". Yuck.

(For those who don't understand, this what the original WinDbg looks like --- simple and functional: [http://sandsprite.com/blogs/images/main_ui.png](http://sandsprite.com/blogs/images/main_ui.png) )

<comment><USER2> The overhead varies depending on how cpu/IO bound the application is. IO isn't really affected, so IO bound applications tend to not see a big slowdown. In theory, you could see a very large slowdown in the worst case, but in the average case for a "medium sized" process the slowdown would be noticeable but not affect the usability. This technology isn't based on tracepoints, it's based on in-process cpu emulation. The emulation overhead is on the order of 10-20x in many cases, whereas tracepoint overhead would be on the order of 1000x I believe (maybe worse).

If there is something specific you dislike about the visuals of WinDbg Preview, let us know through the feedback hub or emailing firstname.lastname@example.com. We realize that folks that have been using WinDbg for 20 years are likely to not be interested in a new UI, but we face 20 years of legacy code every time we want to add a new feature to the UI. As an example, the new WinDbg UI has a javascript window for writing scripts that extend and automate the debugger. It took us approximately 8x less time to implement in WinDbg Preview than what we estimated it would cost in the legacy UI (and a much more junior dev was able to do it as well). We want to innovate without disrupting folks that have effective workflows in WinDbg, so we really want to hear feedback on the new UI. If there are specific things that we can change to make you more efficient in the new UI, please let us know.

<comment><USER19> _We realize that folks that have been using WinDbg for 20 years are likely to not be interested in a new UI, but we face 20 years of legacy code every time we want to add a new feature to the UI._

You can rewrite the UI code so it's easier for you to work on internally, but to the user it looks and acts like it was before --- but proceed cautiously[1]. I'm not against adding features and TTD sounds extremely useful, but having in the overview page some slight contradictions and a screenshot of a dumbed-down UI with obvious WTFs like the two duplicate lines _really_ soured the first impression for me. (Looking at it again, I now see the path in the titlebar has been cut off, despite plenty of empty space after it...)

[1] [https://www.joelonsoftware.com/2000/04/06/things-you- should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never- do-part-i/)

<comment><USER2> What duplicate lines are you talking about?

The debugger isn't written from scratch, just the UI. All of the underlying functionality is essentially the same, just in a more usable shell, and if you collapse the ribbon and retheme the UI to look like the 90s, you could almost squint and think it was the old WinDbg. The change is clearly very polarizing, but we're nearly at parity with what you could do in the old WinDbg UI, and we've already been able to give people features that we could have never dreamed of supporting in the old UI (not for lack of trying). The JavaScript support is just one example.

(Also, the cut-off title bar was an issue in the Fluent.Ribbon component we use, and I think it's fixed in an updated version that we're taking soon)

<comment> bluem-ap > What duplicate lines are you talking about?

I'd guess that userbinator is referring to the ribbon items "Command", "Memory", and "Source" where the group name on the ribbon has been given the same name as the single menu below it (in contrast to something like Word where the contextual ribbon items for a table are Table, with Design and Layout as children).

<comment><USER2> Oh OK, that makes sense then. Yeah, that's been fixed in current internal builds and will go out on the store soon.</comment></comment></comment></comment></comment></comment>


Ask HN: Which project idea should I pursue?  - <AUTHOR>

I am suffering from paralysis of analysis and would like HN's advice on which of the ideas listed below I should develop.
A) Video voice mail Facebook App.  Most of my extended family, whom I have not seen physically in years because of geographic diversity, is on Facebook.  This app would enable us to send each other multimedia messages via the Facebook interface.
B) Telecommuting online workspace.  I enjoy telecommuting, but have found that managers are fearful of losing the ability to monitor my work progress if my butt isn't in a chair in an office.  This tool would allow the definition of project tasks, track my time on those tasks, report this information to my managers and myself, and have a document sharing facility.
C) Kid-friendly knowledge app.  My Dad used to just hand me the encyclopedia when I wanted to read about saber-toothed tigers, but I feel uncomfortable sitting my son in front of a computer when he has similar questions.  This app would contain a filtered sub-set of resources like Wikipedia, Project Gutenberg, and public domain MP3s.
I would personally use each of these ideas.  And, I would probably turn whichever project I choose into a business if others found it had utility.
So, HN, which idea do you think is best? <comment><USER2> C) especially if you can do it as an iPad app or at least iPad friendly HTML site.

Have "daily features" and my kids would be going there a lot.

I'd open my wallet for that.

<comment><USER3> Having recently seen a three year old with his own iPad I think that's a worthy pivot of the original idea.

<comment><AUTHOR> A few years ago I met a youmg cousin of a college friend who had his own computer at home. I had my first compy at 17, this kid had his at 5.

</comment></comment></comment><comment><USER4> Everyone here seems to pick C, which is the one that I am least enthusiastic about. I'm not convinced that the dangers of a kid browsing the internet are significant. Though of course what matters is what parents of these kids think. Still aren't there enough internet for kids filters already?

Make something more unique, like a quiz where the kids have to find the answers on Wikipedia. Or custom made videos a la sixty symbols or kahn academy that explain something. Or a site like reddit for kids for sharing "hey this is cool!"-stuff. Or a community site where kids can work and discuss projects they're working on. As a kid I'd have loved a site for discussing and sharing experience with other kids how to make the best water rocket, making a water electrolysis apparatus, making trebuchets, making websites, fun chemistry experiments etc.

B seems like a good idea to me, though I wonder how many competitors already exist. A simple tool where multiple people can create a tree of tasks and indicate that they are working on a certain task and set expected time of completion would be useful to me. Though for me personally the collaboration aspect wouldn't be so useful, more useful would be something tailored to freelancers: a website that published certain parts of the task tree password protected to help show clients what you're working on and what progress you're making. Of course you're in an incredibly crowded space here.

<comment><USER5> _I'm not convinced that the dangers of a kid browsing the internet are significant._

I think that they are significant. I'm saying this as someone who grew up during the time period when parents had little to no idea of what sort of deranged things were on the internet. A kid could erase the history and clear the cache and their parents would be none the wiser. I'm not in general a supporter of censorship on the internet but I saw some things that are frankly ridiculous for a 7 year old to see. I'm not talking about nipples or vaginas either, you all know that there is some really weird stuff out there. There is a large gray area but I strongly believe that there are things on the internet that an elementary school child shouldn't see.

<comment><AUTHOR> That is why I would be uncomfortable just putting him in front of a computer to find out about saber-toothed tigers.

</comment></comment></comment><comment><USER3> A. Interesting idea but how would you make money? Advertising inside an app that carries advertising itself doesn't sound viable. If you charge for subscriptions how do you compete when Skype comes bundled into Windows?

B. I've looked hard at that space. Software isn't going to suddenly make managers become telecommuting friendly. I thought the market would eventually make it happen but that doesn't seem to be the case. There's a pretty large differential in coders wages between the Valley and the Midwest but you don't see companies embracing telecommuting in large numbers.

C. This is the best idea in my opinion. There are multiple revenue options but you've got answer how you will distribute it? I would also consider seriously marketing to the school at home market. It's a sizeable niche that you could target inexpensively and once you're successful you can build out from that beachhead.

</comment><comment><USER6> Facebook already has video voicemail. Half the time it breaks during a recording and you have to start your message over again. If you can program better than the Facebook team, success! Even if you build a worse product a lot of people might nevertheless try it, and there's your ad opportunity.

The project collaboration management space is pretty crowded. If you go down that road, differentiate. Own a segment. The work of a telecommuter is identical in most ways to the work of a commuter. Go niche or don't play.

Parents can't buy enough toys and crap for their kids. Make something that will truly engage kids. Your idea of filtering public domain search results has limited financial potential. Make a game. People pay for games, no one pays for search.

</comment><comment><USER7> A. Skype and Facebook are close on that and you would be on Facebook's platform.

B. Has good promise. Workers wouldn't like it but it may put managers as ease.

C. Has good promise. You could make it into an app and focus on some niche content.

<comment><AUTHOR> I used something like B at my last job, in which our office was in Virginia and I worked from the Alaskan Bush, but the system we used was a bit cobbled- together.

With C I purposefully would not make it niche so that my son could explore a wide-array of resource. The novel aspect would be automatically rating/filtering public domain content to exclude non-kid-friendly material.

</comment></comment><comment><USER8> I think the kids/young parents market is underserved, I'd pick C

</comment><comment><USER9> A)

An app that increases monitoring by managers isn't going to make anyone happy, and kid-friendly apps are pretty hard (because their users grow out of them so fast).

</comment><comment><AUTHOR> Thanks for the responses everyone!

So far, Project C is the winner. Frankly, I am surprised about the positive responses to it. I was hypothesizing that A would get the best response. So, I am a bit surprised. But, pleasantly surprised nonetheless. :)

Now, I am going to start sketching out details about just what Project C would be and how it would work. I'll let HN know when I have something to review.

Thanks again everyone!

</comment><comment><USER10> I'd say A, though I wouldn't be surprised if Facebook were working on something similar as we speak.

B meanwhile, just bothers me (I wouldn't want to work under such circumstances), but perhaps there is a market for such a thing. If I'm not mistaken, ODesk has a similar, Big Brothery package of their own....check what theirs does, and see if you can improve it.

I can't comment much on C, so I won't.

</comment><comment><USER11> B is awful idea ... A and C are great. I would go for C - parents will spent money for an app for their kids without even thinking about it. And with A you might be going up against something that FB is going to release in the future which will just crush your business.

</comment><comment><USER12> I think a) is the most unique - there are already quite a few companies going after b) (FengOffice, Zoho Project, etc), and c) seems like it would be more difficult to monetize. It also might be easier to develop and market a Facebook App, depending on your skill-set.

</comment><comment><USER13> Assuming you have equal passion for each of the ideas, I think you should choose the one which you feel:

\- has the biggest possible market \- has the lowest costs (e.g. maintenance, support, marketing) \- is easiest/quickest to implement

<comment><USER14> market penetration strategies can be more important than market size.

for example, a smaller market with better acquisition strategies could be better than a larger market with nebulous or not unique acquisition strategies.

</comment></comment><comment><USER15> A) Pros - viral, Cons - monetization, fickle hardware/drivers/bandwidth

B) Pros - enterprise space, Cons - enterprise space

C) Pros - Would run well on tablets, a growth market. Cons - You are trying to build a search engine.

</comment><comment><USER16> Not (B), the space is already over-saturated. Every second designer on Dribbble appears to be working on some sort of online collaboration / team management / invoicing something for telecommuters.

</comment><comment><USER17> A: You can integrate tokbox for that.

B: What is the difference between your idea and a classic online project management solution?

C: Buy your kid an ipad :)

My vote: start with A.

</comment><comment><USER18> No suggestion as to which to go with, but if you go with C, drop me a line when you have an MVP and I will promote it a little. (I still belong to some homeschooling lists.)</comment>


Spike Lee "Seeking Kickstarter Handout" - <AUTHOR> http://www.thesmokinggun.com/buster/spike-lee-kickstarter-campaign-574321

<comment><AUTHOR> Personally, I think its sad that stars who can easily get their projects funded through the traditional channels are now sucking money away from independent projects on kickstarter. Almost as if they're not satisfied with taking only some of the pie, but they have to make sure they're making every dollar that's out there.

It seems that they have seen the challenge provided by kickstarted competition, and have decided to fight fire with fire.

<comment><USER2> My initial reaction was similar to what you've stated. Then, I realized, it's their own money and they can give it to whatever or whomever they wish.

In the last month and a half or so, I've given hundreds to the EFF and similar organizations. Just as I'd be offended if someone tried to tell me how to spend my money or whom I should give it to, I feel that shouldn't criticize anyone else for how they choose to spend theirs.

<comment><AUTHOR> Oh, I have no issue with the people contributing. It's the stars, which I expect we'll start seeing more and more of, who will more and more start leveraging the independent channel for their fundraising, even though they certainly would have far less trouble raising through traditional channels (or, in the case of Lee, could finance that project directly without breaking a sweat).</comment></comment></comment>


Ask HN: Making a low cost interplanetary "weather balloon"? - <AUTHOR>

A childish indulgence, but something I have thought about over and over again and wondered, it's hard, sure, but really, how hard?
Putting stuff in orbit and maintaining it there obviously needs a lot of precision, resources, hard work. But what about 'weather-balloon' like bare minimum project whose goals could be something like:
1. Have goals that do not require a ton of precision, for example go as far as possible, take as high resolution pictures as possible etc.
2. Not worry about losing the craft, perhaps eventually just crashing into the planet and sending that information back. 'Do one thing and do it well' goals of all sorts.
3. Be cheap enough that multiple of them could be sent to account for failure, so more of a spray-and-pray approach as opposed to making one single craft that is absolutely bullet proof.
Required stuff that comes to mind:
1. A rocket with tons of fuel to leave earth.
2. A very very tough ball/craft to reduce drag while dropping onto various "space rocks" and weather small impacts.
3. Shielding from known interference/damage causing factors.
4. A propulsion system for the craft in space - Solar/Nuclear/Magic?
5. Tons of redundant sensors/cameras depending on what the minimal set of goals for the project are.
6. A rock solid high power communication/relay mechanism.
7. A bare minimum navigation system. Perhaps a self destruct mechanism to not fuck up other big missions (NASA/SpaceX) etc?
Sounds pretty damned childish and perhaps like every kid's fantasy, I know, but would love to hear any thoughts on how outlandish it really is. <comment><USER2> What you've outlined is the "Faster, Better, Cheaper" policy. You can read some about that history at [http://amyshirateitel.com/2012/03/06/should-nasa- reconsider-...](http://amyshirateitel.com/2012/03/06/should-nasa-reconsider- the-faster-better-cheaper-approach-to-exploringmars/) .

The basic problem is that it costs something like $2,000/kg to get something out of earth orbit, and 1 kg doesn't get you much. For example, a literal "ton" of redundant sensors would cost $2 million. Just the launch cost for Galileo (to Jupiter) would have cost $50-$100 million or so of its $1 billion cost.

Instead of having "tons of fuel", the cheaper option is to use complex orbits that take advantage of gravity boosts. This allows more weight for sensors and less for boring fuel. But it can take more time.

There's little need to self-destruct. It's expensive to carry a bomb out to Jupiter. Instead, we 'deorbited' Galileo into the planet when its mission was over.

The spacecraft isn't the only cost. There's also time on the Deep Space Network to be able to send and receive messages with the craft, and people to maintain things and analyze the data.

You could make it cheaper on the ground by using a higher power communication system. However, that makes the craft heavier, which costs more money, and reduces what else the craft can do. Rather than having enough power to transmit flyby data live, it's better to use a lower power system and send the data over several weeks. After all, in most of space there's a whole lot of nothing going on.

There is no drag in space. Shape doesn't make a difference.

You can see now some of why mission planning can be very complicated. More fuel means fewer sensors and less transmission capability, but can make a shorter trip or give more maneuverability at the end. These can all affect the mission goals.

</comment><comment><USER3> Most of it I can see working - going faster/further does basically come down to adding more fuel or reducing payload.

The navigation and communication would be where you run into problems. I note that you have specified that as rock solid, unlike the other aspects. Over long distances, communication needs to be directional - you have to know exactly where the spacecraft is (perfect navigation) or it sends no data back and therefore isn't doing anything useful.

Interestingly, this issue doesn't apply to a manned spacecraft that can make unexpected changes without being in contact with Earth, but that doesn't fit too well with the redundant/disposable concept.

</comment><comment><USER4>
       A silly thought:

     We currently don´t have the tech to build a practical

space elevator, but what about one for small payloads, for these bare minimum projects?

<comment> T-hawk There's no such thing as a small scale space elevator. The difficulty in reaching orbit or elsewhere in the solar system is not altitude, but enough horizontal velocity to continually _fall and miss the earth_ or reach escape velocity entirely.

A space elevator must stretch to at least geosynchronous altitude which is 35,800 km. Low earth orbit of 300 km sounds like 1% the effort, but does not help. The top of a 300 km structure on the equator would move at only 0.25 km/sec, nowhere near the 4 km/sec needed for orbit. (It could help if you built a launcher or railgun on top of it, outside the atmosphere, to skip air friction, but it can't literally elevate you into orbit.)

<comment><USER4>
      I didn't mean small scale as in not reaching orbit with it, but as having a small payload.
      I thought the weight of the elevator and its maximum payload with available materials were what keeps it from being built today.</comment></comment></comment>


Time to forget global tipping points (2013) - <AUTHOR> https://www.newscientist.com/article/mg21729070-200-time-to-forget-global-tipping-points/ <comment><USER2> This article gives some couched pseudo-philosophic reasons why we should believe "tipping points" don't exist, without any citations, numbers, or scientific observations. Sorry, but you're going to have to do better than that. Data, or it didn't happen.

Also, this article was from 2013. Scientific understanding has changed since then.</comment>


Red hair gene variation drives up skin cancer mutations - <AUTHOR> http://sciencebulletin.org/archives/3136.html <comment><USER2> Another reason to cover up in the summer sun</comment>


200+ Seattle Startups - <AUTHOR> http://seattle20.sampasite.com/blog/200+-Seattle-Startups---November.htm <comment><AUTHOR> Would be cool to put this on Goog Maps along with other global startup regions.

</comment><comment><USER2> Robot Co-op web-apps seems to be an interesting hobby projects.

</comment><comment><USER3> To put this in perspective, Bill Gates's $50 billion, if split evenly amongst 200 startups, could fund each to the tune of $250 _million_.

Or he could fund them each for $15k like Y-Combinator and still have $49.997 billion left.

Isn't it interesting that before the Winter 2008 batch, the 60-ish YC companies represent less than ONE million invested (initial investment), _combined_?</comment>


Extreme rainfall triggered the 2018 rift eruption at Kīlauea Volcano - <AUTHOR> https://www.nature.com/articles/s41586-020-2172-5.epdf?sharing_token=6LYDO8JoCHQkNa_zM3cJctRgN0jAjWel9jnR3ZoTv0P_UKQLNI_4RagXctaNlQzYXL_kHNotNaTmeRUagcvADMe6baXcGd53G7OFNSitk29E4QvfzK11HRvajPnhuXW_AU4vT4hPNMlg-Mj7NPYrokLBc0wXD1gYdCoV9AaoQI3Xkt2PhC4YpYmcU6t3HuZI-NPJ6G55CXiUk83CPfLchAsJadBBA9hts1AHv0tANpHbl1NNqzrKAK0aAqlX9AnXeNsCbB0687TCIsb0PCH1og%3D%3D&tracking_referrer=www.sciencenews.org <comment> evan-arm For what it's worth, the scientists at the US Geological Survey who study Kīlauea do not agree with the Nature paper:

[https://volcanoes.usgs.gov/observatories/hvo/hvo_volcano_wat...](https://volcanoes.usgs.gov/observatories/hvo/hvo_volcano_watch.html?vwid=1461)

"""

Our analysis indicates that increasing pressure in the magmatic system, which far exceeds the change in pressure modeled as due to rainwater infiltration, was the primary driver in triggering the 2018 eruption.

For HVO, the smoking gun is found in the ground deformation record across a broad region of Kīlauea Volcano leading up to the eruption.

...

In summary, our consensus interpretation of HVO's monitoring data is that magma pressurization was the driving force in triggering the events of late April and early May of 2018.

No external process, such as rainfall, is needed to explain this.

But what about the rainfall hypothesis? While the role of groundwater and rain infiltration impacting the behavior of the volcano remains an interesting area of research, we know that extreme rainfall events have occurred many times in the recent past when no eruptions occurred, and the spring 2018 rains were no greater than many previous rainstorms.

"""

</comment><comment><USER2> Strange to think something as powerful and seemingly primal as a volcano could be triggered by rain, a phenomenon we dont consider as nearly the same level of fundamental primal power

<comment><USER3> Cyclones can get pretty crazy. This one deposited 6m worth of water over an island over the course of a few days: [https://en.wikipedia.org/wiki/Cyclone_Hyacinthe](https://en.wikipedia.org/wiki/Cyclone_Hyacinthe)

</comment></comment><comment><USER4> Add volcanoes to climate change outcomes

<comment><USER5> No, this is a surface phenomenon. No amount of rain is going to determine weather a seafloor volcano forms or is active.

<comment><USER4> Who said anything about seafloor?

<comment><USER5> Kilauea is in Hawaii right? Those islands are all sea floor volcanos that reached the surface.

<comment><USER4> And with changing weather patterns and more evaporation I'd expect more rain in some places, probably around some volcanoes too.</comment></comment></comment></comment></comment>


Ask HN: Will being self-employed hurt my employability? - <AUTHOR>

I'm considering becoming self-employed for a stint to bootstrap an idea that has gotten a lot of positive feedback from individuals who have tried it. Essentially, planning on picking up contract work and using that to fund the development of the idea. Should I be concerned about this hurting my future full time employability if it doesn't work out? <comment><USER2> Let me start by saying that I've founded and sold 2 companies one for a big return and one that was a soft landing. The first co I started when I was working full time at a job.

To answer your question:

Since you are self employed you can put whatever you want on your resume --ie you can call yourself the VP of Development, dish washer, or whatever. In fact, I have a friend that called himself VP of Business Development for his company in the early days.

So I don't think it will hurt much from a political perspective. You just need to be able to tilt the narrative to your favor if things go wrong.

ie: "I left XYZ company because I wanted to try to solve this very important problem. I starred the company, got investors, hired a team, delivered product to customers, and we ran into some market difficulties so shut it down and am now looking for a job"

The one thing that will change, however, is you. When you pass through the looking glass & start your own company, you will fundamentally change. You will develop skills in many area and you will know what it feels like to work on something that you really love that is really difficult. This is what makes it the hard to work a job after a project. Because you know what that feels like and you will want to feel it again. So you will be VERY picky.

Also, there is the power law to consider. If you start a co, the skills you acquire will compound over time. Quickly they will become the biggest asset you have and you will realize that.

My #1 advice for you is to stop thinking about what will happen in a downside and look at what will happen in an upside. The more you think about how a new venture can screw you, the more likely it will.

If you want to chat more DM me on twitter @jsfour

<comment><USER3> > The one thing that will change, however, is you.

Very true. I might add, your approach to solving client problems will likely grow more sophisticated. Mid-tier corporate managers and HR flunkies might not get you, but true decision-makers will.

While you're ramping-up your contract business, here's a good read on consulting> [http://www.summitconsulting.com/store/ultimate-consultant- in...](http://www.summitconsulting.com/store/ultimate-consultant-info.php)

</comment></comment><comment><USER4> The short answer is that you're right to ask the question because it _could_ hurt you badly.

A lot depends on your specific situation. How accomplished and in demand are you right now? Do you have a network of people who would hire you in a heartbeat or at least enthusiastically recommend you and actively help you find a job? If you are in demand (i.e., frequently turning down overtures from recruiters) and/or you're very confident that if you lost your job tomorrow that you could find another equally good job in a matter of a couple weeks or less, then going out on your own for awhile probably won't have any negative impact.

On the other hand, if the above does _not_ describe your current career situation, then I'd think hard about it. There are _many_ recruiters and hiring managers who look at self-employment as barely better than unemployment. That's outrageously stupid, but it's reality. I personally know half a dozen people who experienced _significant_ setbacks to their careers after leaving their jobs to try self-employment or work on their own startups. (But, again, a lot depends on how hireable you are currently, where you live, etc.)

</comment><comment><USER5> Assuming you are technical, even a failure is probably a net positive to your career prospects. This is particularly true if you are very early in your career, or are later in your career and have been involved with some well- known or successful companies along the way so far.

I view entrepreneurial experience as a positive that tends to correlate with intrinsic motivation, follow-through, and analytical risk-taking.

Obviously YMMV, and a lot depends on how you execute. If you have a crappy idea and throw years of your life away with no demonstrable progress, obviously it's not going to be easy to tell a story about. But a failure reasonably well done will be a good learning experience -- and obviously even a modest success has lots of upside.

The biggest real issue is opportunity cost, factoring in not just income but the potential to be part of something epically successful and all the experiences, halo effects, and relationships that come from that.

</comment><comment><USER6> I do not think self-employment damages your employability so long as you have something to talk about at interviews. Self-employment is still employment. Any employer that is going to be successful in talent acquisition among the younger generations will know this.

The tech industry illustrates this regularly with company cultures that embrace diverse career backgrounds.

Of course i think your field will probably determine how much my statement applies. For my field in software, independent contracting is a common feature in ones work history especially for the younger generations. I would look at your peers in your industry and domain for clues.

</comment><comment><USER7> ...becoming self-employed...future employability...

Bwahahahhahaha.... Wait, sorry. Ok, has working for clients hurt my future employability?

Who cares? I wouldn't take a job now if they offered to pay me!

</comment><comment><USER8> Yes it will. But only at the companies where you wouldn't want to work at anyway. Enterprise companies with cushy layers of middle management love 'B' and 'C' players.

</comment><comment><USER9> It never hurt me, back when I was applying for honest jobs (self employed now). Whether or not I worked for other people, I was always doing things I knew would advance my career.

</comment><comment><USER10> As long as you have a skill set that the market wants... you won't have any problems.</comment>


POPCOUNT, the "NSA Opcode." - <AUTHOR> http://www.moyogo.com/blog/2005/09/secret-opcodes.html

<comment><USER2> From talking to a processor designer, popcount is expensive to implement, which is a more plausible explanation than "OMG NSA conspiracy". Also, some of the latest billion-transistor processors _do_ have popcount.

Secret instructions wouldn't work on emulators such as Bochs or Virtual PC because they aren't in on the conspiracy and the resulting errors would raise suspicion.

<comment><AUTHOR> > Secret instructions wouldn't work on emulators

This would be a good point were it not for transparent (in every way save for slowdown, which would be dwarfed by the slowdown of using an emulator in the first place) fall-back. All that must be done is for the OS to hook the invalid-opcode interrupt and run a short routine which emulates the instruction in question. So apps will still work, but without the magic speed- up of the secret instruction. This assumes that the OS vendor is in on the conspiracy, as Microsoft was found to have been on two separate occasions. (Read about how they killed OS/2.)

You could still find the "evil" code by monitoring the invalid-opcode trap using the emulator's debug interface.</comment></comment>


Where Growth Is Found: The Magical Sugar Packet - <AUTHOR> http://www.nevblog.com/the-magical-sugar-packet/

<comment><USER2> Is that a dick in the comfort zone?</comment>