Hacker Newsnew | past | comments | ask | show | jobs | submit | usernam's commentslogin

At least here, the driver of the vehicle hitting anything (another car, especially a person) is /always/ responsible, because you're supposed to be attentive for unexpected events. And that's how it should be. Why do you think otherwise? If you don't see clearly in front of you because of scarce illumination, you should go slower.

Unless assisted driving is close to near perfection (that is, it becomes a true auto-pilot without the need of assistance), we're going to see much worse numbers of accidents on the streets for assisted-driving cars.

Assisted-driving requires the same, if not more attention, as it essentially becomes like supervising an inexperienced driver that is prone to make stupid mistakes in otherwise normal circumstances. If you ever had a kid, you should be pretty familiar with how stressful this is.

But thanks to the PR spin, the driver is led to think that he can keep less attention, until he pays none at all. Assisted driving is even more boring than regular driving, lowering the attention span.

What could possibly go wrong?


The barrier is lower for applying, but as many other posters saying, there is simply just interest in quick ROI and zero willingness to think long term.

I recruited for several years for my companies too. First thing I noticed, there is huge variability in CV for each country. When I receive a CV from an indian person (from India), I don't know if I should expect 100% lies or what, even from qualified seniors. On the other end, I could put my hand on coal if the same CV was written by most germans. Which is bad, because the CV or cover letter become essentially useless as a metric.

To reduce the number of applications we introduced simple tests to submit along with the CV. It does wonders, but I personally hate it. As a senior dev, I keep asking: would I apply to my current application? I have to answer that no, I wouldn't. I have plenty of public projects to investigate my abilities if needed, and I do expect some minimal amount in investment from both parties when hiring.

We also raised the requirements from applicants ridiculously, essentially expecting them to work on core features from tomorrow. Again, completely unrealistic. And again, by our own wording, I would be afraid to apply. We are definitely selecting over-confident candidates (or desperate).

And it's sadly also true that the industry has no apprentice jobs anymore, although there is plenty of need. There are some career paths where I would jump ships despite my lack of expertise to follow my interests. Starting from zero doesn't stop me, but there are simply no opportunities: junior jobs are not really junior anymore. They are simply paid less.


> As a senior dev, I keep asking: would I apply to my current application? I have to answer that no, I wouldn't.

Looking at it from the other point of view, are you getting enough candidates that you are comfortable with via your current application? If so, the question becomes whether it would be enough of a benefit getting "you" (people like you) to apply to your current job... vs the cost of having that many more people to filter through.

Just like the code you deliver, the application process doesn't need to be perfect (because being perfect has a large cost associated). Instead, you have to weight the tradeoffs and pick the solutions that best match the resources you have available to the outcome you want. You need "good enough" (I hate that term, it sounds like "bad" to my ears, but it's literal meaning is correct here).


We're getting enough candidates, but many good ones are simply turned off at some point because the salary or position doesn't match the high expectations we implicitly set.

This, in turn, results in a process of exclusion during the process more than actual evaluation (which then begs the question: why put such high requirements?).

I'm pretty sure we're discarding individuals which are just too afraid or see themselves too conservatively. I'm not afraid to say that I ended up in my position by pure chance, and probably wouldn't pass the hiring method we currently use, despite being here for quite a long time.


>> When I receive a CV from an indian person (from India), I don't know if I should expect 100% lies or what, even from qualified seniors.

Be careful about going there. Discrimination is illegal & unnecessary.


I work in a company with a lot of staff from India (TCS consultants). I can confirm that some of them have a fairly flexible relationship with reality and facts, and it can be incredibly irritating at times. I agree that it is most likely a cultural thing: decorating / distorting facts to achieve goals is looked upon more favorably in some cultures than others, with all the moral hazard and distorted incentives that implies. It is, however, worth noting that not everyone from India I have met is like that or that one attitude or way of communicating is automatically better than another. Once one learns to parse the code, life gets considerably easier.


TCS supply L1/L2 internal support services where I work, and while the more senior members of the teams are very good at their jobs and take a proactive part in providing supporting, the ones who have been there less than 5 years (made up number, the less experienced/greener staff) struggle to follow simple instructions without several confirmations of the actions, even when pretty comprehensive documentation has been provided. It's quite an interesting, and often frustrating, dynamic.


I'm not really making any. This almost seems like a completely different way to present yourself which is taught to people.


Can you share your opinion about other countries as well? It's an interesting statistic which I, suspect, not many would be willing to discuss publicly and non-anonymously.


I would say that indian CV are simply on another level, I have no clear idea why. We're posting positions online, and the openings are often automatically indexed by several job search engines. Maybe this is because indians are just more exposed to online hiring, working abroad and generally simply try to get an interview.

Let me reinstate that also this is not universal. We had very good candidates which didn't inflate the resume, thus my point that I really cannot look at the CV by itself. This is very detrimental for both.

I took "germans" as a stereotypical example here. Thinking back, most qualified applicants anywhere in EU are in a similar ballpark. I would say a small amount of inflation is common, but senior applicants generally match much more closely the qualifications they presented. I didn't have many applications from other eastern countries to say anything else.

I'm also not an HR guy. I just participate in the hiring process when the need arises.


Marginally related: is there something native (and for linux/unix) equivalent to shadertoy? When debugging a sharer it's quite handy, but the web interface is just too laggy for me.

I'm currently using my own simple test rig, but I'd like something more refined.


Bonzomatic is an equivalent of Shadertoy designed for live-coding competitions: https://github.com/Gargaj/Bonzomatic/blob/master/README.md


But is it? I don't actually think it's bad design. Having system images of a pre-loaded heap is pretty common in many systems and languages. How such systems are generated and loaded vary, but they always come with some tricky issues. This is especially common in lisp-like systems.

The whole lisp implementation is emacs is a bit crummy, but I don't get the excessive criticism against unexec. I consider lexical binding a much a much bigger oversight.


I would have several actual uses for VR, and from the top of my head I'd kill to have proper depth perception and enhanced controls while modeling the solids I have to make.

The headsets make today would meet my requirements perfectly. The price is not an issue. As a coder, I wouldn't have any problems with just a library exposing the display and sensors.

However the VR market is just full of BS and lock-in. I'm not moving an inch on any of these closed platforms.


Razer has an OSVR headset. Oculus is OSVR-compatible. Even Vive has a (less supported) OSVR plugin. What's your complaint?


There's also a Khronos standard in the works: https://www.khronos.org/openxr .


have you actually looked at oculus' API? it is just a library exposing the displays and sensors, and it's probably the most vendor-specific of them.

you could #ifdef between it and any other VR library with minimal effort.


SteamVR literally lets you build for Vive or Oculus with identical code and builds (using Unity)


I'm not sure I've seen any "user interface innovation" done with HTML.

Pick a book on GUI interfaces of the 80ies (for example: Computers Graphics by Foley & al), and see that pretty much all UI paradigms themselves were pretty much explored back then. The concept of the "hypercard" was already there.

HTML just improved on the presentation of it, often worsening everything else. Somehow web apps lowered the expectations of what a computer /should/ do so much that usability itself became an afterthought.

Some of the best designed apps on the web mostly ditch the DOM and layout everything in JS. Hardly "innovative".


I'd say that the web page itself is a pretty innovative concept. The concept might've existed before (Apple's HyperCard dates back to 1987 for example) but the web expanded on that by making use of resources distributed across the network.

There have been many smaller improvements, too. Google's Material Design for instance.


> There have been many smaller improvements, too. Google's Material Design for instance.

Could you elaborate on that? I.e. how this is an improvement, and over what? Serious question.

My overall impression is that it promotes dumbed down interfaces that maximize wasted screen space while minimizing amount of useful information displayed. But I might have just bad luck and constantly encounter applications using Material Design wrong. How does a good Material Design application look?


The material metaphor and the purposeful use of animation ("Motion provides meaning"), dimensions and visual perspective in my opinion is an improvement over merely arranging information in grids.

It's a fresh approach to displaying information in a meaningful and consistent manner.

Both the new Google Calendar and Contacts application are decent Material Design applications in my opinion.


You're trying to conflate document design with UI design. By the writing of the author, he is clearly doing just fancy documents. He didn't even touch the problematic issues you normally face in web development.

You can do pretty neat things with trivial html/css these days, where you needed quite a bit of JS just 5 years ago.

Platform GUI toolkits are designed for controlling an interactive program from the start, a very different usage scenario. They were never designed to be documents to be read from top to bottom. Traditionally, GUI toolkit almost never included fancy text layout boxes just for text display. To give you an example, a simple text label to be used next to a button almost universally could be of a single font with the same style throughout.

I wouldn't even consider this a limitation, because on toolkits with advanced theming (GTK/QT), this allowed for a very consistent layout across all programs, which is clearly a much better user experience for the user as opposed to styled individual applications. Somehow, this crucial bit of /actual/ usability /design/ was lost.

The irony? Current GUI platform toolkits are actually copying the document model of web pages instead, so that your layout skill set can be more easily transferred across systems. So you can finally style your button's label to your hearth's content. XUL is probably the first example of this.

As if "layout" was the major issue in desktop user interfaces (HINT: it's not).

Now we have GUI toolkits which are basically web views that maybe call some native code. In my opinion: a huge failure in engineering and user experience.


I guess it really comes down to the trade-off between customization and familiarity. IME in any given company there's plenty of people going to bat for the former, and hardly anyone that cares about the latter.

On the "sliding scale of giving a fuck" [0], there's usually plenty of graphics designers and managers whose job revolves around giving an '8' for customisation and branding, and most devs seem to consider usability at about a '5' relative to their other work, so they don't offer up a lot of resistance.

[0] http://blog.capwatkins.com/the-sliding-scale-of-giving-a-fuc...


I've had the feeling that modern gui toolkits copy the dom not due to any superiority, but because of the massive developer base it has.


I worked remotely for more than two years because I had to move to another place. I loved the company and they were quite happy as well, so they let me work remotely full time without problems. I absolutely loved it for the first six months, then I quit my job after the second year despite being a "dream scenario" for many.

I generally work alone when I want to think, but I loved the interaction with excellent colleagues and sitting at home with skype wasn't exactly the same.

I would still work remotely for 2-3 days a week, because it's so much more productive for certain tasks, but no more. I do not consider full-time remote jobs.


I’ve always been hesitant to try remote work because it seems like there’d be an added pressure to seek out face to face interactions or else I’d slowly become a hermit. I consider myself an introvert, but even that has its limits.


My take from the experience was that if you have an active social life outside of your colleagues and work is "just work" for you, then a full-time remote job is probably fine. Saves you the commute too.

I do have an active social life, but I expect my work to be something more than "just work". I enjoy what I do, and working at a distance detracts from the experience.


Doesn't work in all situations, but what's worked for me is to treat it as something that you need to keep an eye on, and then liberally take trips into the office.


This has not been my experience, not at least in research or IT/research sector. More hours do not translate in more results _or_ more focus.

I've seen also an inverse relationship in quality of work and work streaks also in other fields, for example a direct experience for me was automated textile production. More hours in this case has a direct relationship with more product, but results in more stupid mistakes and more importantly I've seen less overall feedback from the production line, where employee are just more eager to say "fuck it" and simply do the work as opposed to try to help in improving the production process. There is a fine line between using your employees as a resource or a brutal work-force.

This was an eye opener for me. There is definitely a balance in every part of the production line, and less work is generally good for everyone.


Interestingly, it seems to lose 1/3 of the inputs I'm trying to send...


Yeah, it's super half baked. I can tell you that as the developer. I plan to focus on collaboration in the successor to this project, Mopaint: https://github.com/1j01/mopaint

(Rather than adding it after the fact.)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: