logicalmind

Director: Our operating expenses are through the roof. We've got a dozen developers and we're still behind schedule...

Manager: That's because we don't have any "good" developers. We need to find some of those 10x productive developers and get rid of some of the guys we have.

Director: So you're telling me we can replace 10 developers for the price of one good one?

Manager: That should be true, but the 10x guy is going to want a bit more money.

Directory: Let's do this!

(some time later at the interview)

Manager: Were looking for highly productive programmers and we're willing to pay top dollar. We see you've accomplished X, Y, Z so we want you to come and join our team.

Developer: Sorry, I can't...

Manager: How about $50k more salary...

Developer: Wow, ok, I can't really say no to that.

(some time later the first day)

Manager: Welcome to your first day, here is your team. Get as much information from them as possible because we'll be laying off 10 of them in 30 days. Good luck!

I think the problem is that everyone freaked out with the angular 1.x to 2.0 changes. The angular team, not wanting to lose the 1.x momentum, decided to attempt to write a 1.x to 2.0 conversion tool. The major hurdle to doing this successfully is reliably interpreting javascript code such that it can be understand and converted by an automated programming. Now imagine if instead, all that code was written in typescript. Such a conversion tool would be arguably more simple.

It would seem that if you want angular to evolve in possibly non-backward-compatible ways, then conversion tools would be a requirement. And this is going to be a simpler task with a typed language.

Because Microsoft wants to add tooling in Visual Studio to use this and they obviously would want to use Typescript for that.

Hard to say. It didn't seem like Microsoft had a good strategy for modern web development (javascript/rest/etc.) at least from the client side. They had webforms/MVC but you pretty much had to use client side controls from other sources, like Telerik, if you wanted to do something modern. One assumes that tooling with javascript would be difficult for them to add in Visual Studio, say as compared to the tooling offered for C#. So moving to a typed language allows them to have nice Visual Studio tooling as well as picking a path for modern web development.

This type of mass shaming existed before twitter. The Steve Bartman incident[0] comes to mind. The difference appears to be that it used to only be possible for such things to snowball when the media or a celebrity pushed the issue into the spotlight. Nowadays, twitter allows for quick and easy mass shaming by anyone and everyone.

[0] https://en.wikipedia.org/wiki/Steve_Bartman_incident

I only agree with this if the developers also get to choose the deadlines for the app/features they build. All too often, the higher-ups want a feature but don't want to take the development time necessary to build it properly. And shortcuts are taken all over the place to get the feature done in time. The higher-ups don't care about doing things correctly and don't have any pain when things go wrong. Which makes it more likely to push this sort of behavior.

I think developers should build code that fails in predictable ways with useful error messages that a support team can use to solve problems. If the support team cannot fix the problem with the information provided, then a developer should need to get involved. This way, developers only feel pain if the code they write fails in ways support cannot handle.

In my opinion, most people want to be part of their "team". Where the definition of team is highly dependent on the context. When you're a teenager, you're team is typically your high school. But you can abstract this "team" concept upwards. If two states (in the US) were competing, then you'd support your state. If it was your country competing against another country, you'd support your country. Hypothetically, if aliens attacked earth, it would be quite interesting to watch the earthly team spirit arise and would likely change the perspective of many people and countries. In this hypothetical scenario would Chomsky still not support his "team"? Being part of team high school is bad? But being part of team earth is good?

Specifically, this is for heads-up (two person) limit texas hold'em.

In my simplified view, I think we need to do something about the fact that you cannot build an application today that will not be obsolete in 6 months (at best). And by obsolete, we're not talking about obsolete like a COBOL application. We're talking about relying entirely on frameworks/libraries that may literally no longer exist. Think about an angular 1.x application 5 years from now.

If you're building an application that will take a non-trivial amount of time to build and will have a lifetime of years, what technologies would you pick? How do you train your team members? What is your strategy for maintaining it into the future?

If someone built a webapp 10 years ago, it would be php, rails, asp.net, java, etc. And you can find someone who would (possibly reluctantly) get in there and do something with it. But what about the app built using 20 npm libs. What do they do in 10 years?

I think your comment and perspective hit the heart of the matter. You view your work in isolation. And if you're not working in isolation, you are assuming that your co-workers are in the 99th percentile of coders. If you're making some small webapp or mobile app, then that mentality is fine.

But think about it from a different perspective. Let's imagine you are hired by a company to come in and build a large, web-based, responsive, buzzword, buzzword application for them. It's big enough that it is going to take months to develop and require numerous developers. The strategy of "just writing a JS file and adding a script tag to their html, that's how most of us learned it." is not gonna fly. And if you are spending your time doing "If you can't find what you want, build it yourself, maintain it, and use it" then how are you getting your actual application done? You don't want your devs spending a month of time to build (and then support) some templating library or some such when your real task is to write some kind of CRM application. So how do you go about picking technologies, training teams, building upon existing libraries, etc. in order to build your actual product?

This is a good point. I am not Russian but I learned programming in the same way because I started out doing embedded work. Where a build/deploy/test cycle could take hours to an emulator and debugging was very unfriendly. If you did not do rigorous thinking about your program and what you were doing, you could waste huge amounts of time. I no longer do embedded work, but the mentality has stuck. When I commit my work, it tends to have fewer bugs than what my co-workers produce.

It is a great luxury to be able to work on what you like, especially as a dev. Unless you're a well-known person, I don't think it's that easy to work on what you like, even at google. At least not anymore. Hopefully you guys at facebook can keep the MBA's off your backs long enough to do more cool stuff!

I find this type of work within companies (like google's famous 20% rule) an interesting contrast with non-tech companies. At a "normal" company if you attempt to spend time doing something of this sort, you'd get immediate pushback from higher ups who would likely say "this is not our core competency". With the secondary excuse being that they would not want to release any work like this for fear that it would help the competition.

It does raise the interesting question of whether facebook employees are doing this work just to avoid the work that is the "core competency" of the company. Especially given the fact they don't gain a competitive advantage from releasing the work that facebook paid for into the wild. By this I mean, the company benefit would seem to be attract other talent. And the personal benefit for the devs is to get their name out there are something cool and interesting. Certainly, working on the best way to advertise to users is a lot less exciting/sexy than working on static type checking for javascript.

I'll tell you my story from being in this situation from both sides. Like the OP I consider myself able to do a lot more work in a lot less time than others. Companies I work at tend to take advantage of this. So last year I decided to look for a new job. It didn't take long before I found something and gave my resignation letter to my employer. They immediately setup a mtg with myself and the bigwigs and essentially asked me for what it would take for me to stay. Knowing the rule that you never take a counter-offer, I made the numbers extremely high. Huge raise, huge bonuses for multiple years guaranteed. To my surprise, they gave me everything I asked for.

Then I notified the company I was planning to leave for that I was planning to stay where I was working. They asked me what the offer was and I told them. Within a day they offered me even more! What an embarrassment of riches this seemed to be. So I went back to my employer at the time and said I was actually leaving. This made them really mad. But Left and went to the new job.

It turned out that the new job was completely different from what I was sold. I was leading a team of well over 30 devs (all but 2 were consultants from large consulting firms) across multiple countries around the globe with the intent of performing 24 hour development. We had meetings every 8 hours to do handoffs between the timezones. My first day was over 14 hours of work in the office. The first weekend was completely consumed by a horrible deployment. The team members were absolutely exhausted, sleeping at their desks. This was an absolute nightmare. I was essentially brought in to get rid of the consultants (to save money) and replace them with in-house staff. I was initially brought in as a lead architect/dev. So I went to my boss, who hadn't talked to me my entire first week and never even introduced me to the team, and asked him what the timeframe was for me taking over this team and he said "within a month we'll be letting go most of the consultants". I was absolutely shocked and immediately begin trying to find a new job and it took a few months of true hell to do that.

There is a lot more to this story, you can email me if you want to hear it. But my points would be, if you're talented, people will take advantage of you. And you could end up in a situation where a company will take advantage of you up to your limit. The consultants I worked with were from large well-known consulting firm and I'm sure they were paid well but their lives were hell and they had no recourse. Almost all of them smoked chronically to deal with their stress, amongst other things. If you're like me, you'll find that you certainly can be more productive but you'll end up with two choices. One, work at a normal job where most of your time is free for you to be productive at things you want to do. Or two, be your own boss and choose your own workload.

I don't really understand this comment. If you're posting on HN you probably care about startups. And generally, startups don't or can't provide health insurance to their early employees. Which leaves the startup game to the very young and very healthy. The ability for everyone else to have the opportunity to leave their existing job (aka healthcare source) and strike out on their own should surely increase due to this.

Location: Western Suburbs of Chicago (Naperville area)

Position: Sofware developer

Full time position, no remote. Financial institution that uses C#/ASP.NET to make webapps that support various financial services. We have a large application upcoming and are moving towards a REST architecture using javascript client-side and asp.net webapi backend. We're looking for a developer with experience in any client-side javascript technology (current line of thinking is to use angular, but open to alternatives) utilizing REST to become part of the team that designs and implements the platform. Knowledge of server-side factors of REST also desirable (ideally c#/asp.net/webapi but not required).

If interested, contact me via email and I can provide more details. Email is in profile.

If you want to add a killer feature to this, add better handling for non-referenced dependencies. By non-referenced I mean they don't exist as a project reference like a dll would. For example, if you're doing a web project and you depend on say angular. Angular isn't added as a project reference. Nuget/Visual Studio do all kinds of oddities to work around this. Unless there is already a solution to this that I don't know about (besides using two different package managers).

If you think about this in minimal terms, you have a merchant(pos), a purchaser/consumer, and an intermediary (though this would not be necessary for direct non-credit payments, like non-escrowed bitcoin for example). In an ideal world, a pos could publish a message like "transaction #N initiated for $X" to some "payment bus". Then the consumer would have to then publish a message like "User $Me agrees to pay $X for transaction #N".

If this were something like bitcoin, the payment could be wallet to wallet. If it were credit, some processor would have to know that they process transaction for "$Me" and find transaction #N to settle it back with the POS.

So the question really comes down to how you would implement this "payment bus". It seems like it could theoretically be something like the stock market. In fact, credit companies could be market makers and offering to settle transactions for consumers at different rates. This would have to be fast enough to be usable, but it seems like that issue is solvable with HFT solutions. But how would you get existing companies who make their own custom and profitable buses to all agree to use one generic bus and move the money making to the credit side?

I didn't look at this in detail, but this appears to also be using refresh tokens. Getting clarity on refresh tokens is a bit tough, but they are intended to allow one to request a new access token when the access token expires. I don't think refresh tokens are intended to be stored client-side as they are with this. If a refresh token is compromised, it can be used to request an access token for the user.

"Even further, what plausible harm could come from a picture of a kid in a tub, for example?"

Knowing the kind of data mining that occurs with text, one would only expect that future mining would occur with images as well. So what happens when all public images of you from birth to present are indexed and used to make decisions about you? For example, what would happen if you tried to get health coverage and the company could look into these indexed images for all contact with known carcinogens to determine your ability or cost for health coverage?

Do you employ HVAC service people to do on-site repairs or subcontract?

I'm not familiar with the details of the tesla driveline but is the definition of "drive unit" well-defined? Is this the equivalent of the engine? Or the drivetrain (including transmission-equivalent and axles)?

In my experience, there are two kinds of programmers. Top down and bottom up. Top down programmers have good success going from high-level languages to low-level. Though, learning a low-level language for them is not really necessary. Bottom up programmers don't grasp many of the fundamentals of programming until they can build them from basic underlying concepts. Some bottom up programmers may never get to a higher level language and end up as systems programmers or embedded programmers, maxing out with C as a high level language.

Personally, I am a bottom up programmer. I started with C and I found it confusing and ended up really disliking programming (I was in an EE program). Then in a later term we used assembly and once I got that foundation, everything clicked. I suddenly realized why C was necessary and what it provided. High level languages were then built up from there.

Everyone is different. There won't be one path.

But presumably you are going to have co-founder(s) or employees. The decision is not just for yourself or your family. Your co-founder(s) will have to accept the same situation and anyone you employ would also be expecting health coverage.

Same here. I've been a developer for years and as I've transitioned jobs I've met a number of really good developers. Any time an idea arises that would make a tempting startup I reach out to people I've worked with to solicit the opportunity to work on it together. Every time I've done so, the inevitable decline always has something to do with healthcare.

Once you're beyond your post-college years and have a wife, and possibly children, the risk of a startup suddenly includes the cost of healthcare and risk of not having any. All of us can make comfortable salaries and have money to take risks on our dreams and be protected from failure by incorporation. But that does not translate to the potential medical issues of yourself or your family which would lead to personal bankruptcy and future employment issues.

I'm not gonna write my life story on hn, but I have the exact opposite experience as you. I grew up in a blue collar family. No real white collar mentors or apparent options in that world. So I followed my dad into the trades. I spent my summers in high school as a plumber (apprentice) and became a full-time plumber after high school, eschewing college even though I was accepted to a number of good schools.

After a number of post-high school years of being a plumber it quickly became obvious what type of life this would lead to for me. In particular, the physical toll. You are often carrying heavy equipment or supplies up or down stairs or ladders. You spend your entire day working with sharp edges, saws, and electricity. Accidents occur all the time and any of them can be debilitating.

You also have to consider the risk of the impairment of others and what damage it may cause you. Let's say a co-worker in IT gets drunk at lunch and comes back to work. He may accidentally drop a table or even a database. That sucks for sure, but in the grand scheme of things, your life and ability to continue working aren't impacted. But consider being on a job site with others and the electrician gets drunk at lunch. He could accidently miswire something that could end up with a severe injury to you or someone else. The risks from the mistakes of others upon yourself is much larger in the trades.

There are lot of things that seem similar. New development is akin to new construction. Both have maintenance and service. But IT is essentially a virtual environment. The data is important to many people and can even have lives depending on it. But in the trades, it is a completely physical environment. There is no undo. There is no restore from backup. Mistakes can and do result in physical injury and death. It is the difference between coming home at the end of the day sulking that you had to do some user support and coming home minus a few fingers because you or someone else sneezed at the wrong time.

My dad is retired now, not by choice. He was on a rooftop holding an air conditioner panel. A gust of wind kicked up and he had the choice of either letting the panel blow off the top of the building onto others below or hold onto it. He held onto it. In the process, destroying his back. He was never the same. That doesn't happen in IT.

Location: Western Suburbs of Chicago (Naperville area) This is not an officially endorsed posting by the company, I'm an engineer at the company looking for someone good to work with. So I can't give full details publicly. If interested, my email is my hn username at gmail.

Full time position, not remote. We use C#/ASP.NET to make webapps that support various financial services. We have a large application in the works and are moving towards a Rest architecture using an angular client and asp.net webapi backend. We're looking for junior to mid-level developers with experience in any client-side javascript technology (preferably angular, but not required) utilizing rest to provide direction/suggestions/input on various factors of the design and implementation. Knowledge of server-side factors of rest also desirable (ideally c#/asp.net/webapi but not required). Knowledge of the client-side is most important.

If interested, contact me via email and I can provide more details.

How about "the internet tollway". If you want to get fast speeds between locations, you'll have to pay the toll(s). Otherwise, you'll be taking side streets to your destination.

In my experience, one easy way to determine how good the job is going to be is based on the pecking order of various departments in the company. At a company that does software, the software developers are usually at or near the top. Alternatively, at a marketing company, the marketers are at the top and the software developers may very well be near the bottom.

You can gather this information in a number of ways in an interview. Simply ask one of the interviewers where their group exists in the company hierarchy. If you don't want to be explicit, ask to look at the area where the developers sit and work. If the area is well done and people seem happy, you're probably in good shape. If the people are essentially stuffed into a closet or makeshift office/hallway then you might want to run.

Generally, try to work for a company that makes money on software or technology. A company that makes money on other products or services is likely to treat software developers as a low-level function of the organization.

The whole payment space is getting really interesting in the last couple of years. Banks and retailers trying to work around credit card processing fees as they became larger part of their balance sheets.