interesting to read all these from the engineer's perspective. from the manager's side of the table things are quite different. If an employee comes to me and asks for a raise then I begin the process to replace them. We give reasonable raises, we pay fair market value and an engineer might make a little more elsewhere but they'll be giving back their RSUs and the opportunity to work on really cool stuff. If, however, they want something else then good luck to them, people are all different and it's a free country, but asking for raises means they aren't happy so they will leave anyway, either way, I begin looking.
when someone joins, unless they are at vp level they really don't have much negotiating opportunity, we make a decent offer and they either take it or leave it. we very seldom adjust the offer.
And since you state up front that you are giving reasonable raises you essentially forestall the negotiations so unless your definition of 'reasonable' is different than the ones that your employees maintain you should have next to no turnover. If that's not the case you might have a problem there.
The 'opportunity to work on cool stuff' is worth $0 to a working dad with a mortgage, so likely you can do this but only to younger people, but people do not remain young forever and sooner or later their expenses will go up. And you sound like you will not be taking their position into account at all.
Employees are sometimes happy. Sometimes they're miserable. Sometimes they're in-between — for complicated reasons, that may lie outside of work.
Firing any employee that asks for a raise is so unbelievably short-sighted, binary, sociopathic, and potentially bad for business (morale, replacement costs, unknown costs), it's cartoonishly villainous.
This is true at most employers, and is one of the biggest contributors to churn and the lower-than-it-should-be pay in our industry. Companies whose offer includes (implicit or explicit) statements about how cool the projects are are peddling the same employees-are-pets nonsense that the "free food/perks" companies peddle, and there is no shortage of labor ready to lap it up.
Yup, and high churn actually makes the projects less pleasant to work with IME. More turnover means the people updating the projects have a weaker understanding of how the projects work, so they create more bugs/cruft than an equally-skilled developer who has worked with the project longer. And by the time those developers know the projects inside-and-out, they are already looking to move on.
I don't automatically do this. I want to know why, and what their value proposition is.
People have things happen and reasons and goals for wanting to change their comp, and frankly, that goes both ways. I've had people want less and to change roles for very similar reasons.
Replacement is expensive, so is commitment and vision. For some people, yes. It's a trigger for replacement. For others, it's a time to discuss keeping everybody healthy and productive.
And there could be options too. Perhaps more money isn't optimal. Nobody knows, until there is a discussion.
I commend you for your honesty. If more employers were this honest up front, the workforce would be a much better place.
Since we happen to be in a sellers market for IT talent, I suspect you would not have very many takers if your prospective employees knew up front that this was your attitude towards them, and they'd be valued so little that asking for what they thought they were worth would mean they would get fired.
You attitude would fly much better in a buyers market, where the employer holds all the cards. Then you could demand whatever you like, and the employee would most likely be desperate enough to lick it up.
It makes him the kind of low-level or middle-manager that certain companies love. His purpose isn't to support his subordinate employees in their work, it's to make sure the company pays as little as possible for as much work as possible, and to act as the first line of defense against employees who aren't "100% on board".
Clearly he thinks that "asking for a raise" puts an employee in the "not 100% on board" category. That makes him terrible at reasoning, and perhaps poor at empathy, and strongly indicates he's not the kind of person an intelligent developer who desires to be treated like a human being should ever have to work for, but I'm not sure it makes him a bad manager per se. He might manage very well in other respects.
maybe, but when an employee asks for a raise, or say they are quitting does that make them a horrible employee. so many people think that work is some big philanthropic organization set up to serve their needs.
"when an employee asks for a raise, or say they are quitting does that make them a horrible employee"
No it doesn't.
You seem think employees are there just to serve you for the lowest bid and if an employee is coming to you with a better offer then, you aren't paying them "market rate".
there are all kinds of intangibles not mentioned here. what if you have an idea that transforms the company's sales numbers or you dream up a better way of doing the builds that reduces integration bugs. So many ways an employee contributes intangibly.
you're right, pay is basically what your peers make +/-
Yes, particularly in the UK the vestiges of the old class system are that no matter what price the market clears at a blue-collar worker can never be paid more than a white-collar manager.
So if you are in a situation where there is a glut of junior managers and a scarcity of talented engineers, then seemingly inexplicable things start happening to salaries.
I'm fascinated that in the UK, software engineers are not viewed as white-collar professionals. That seems to be a rather big difference between the work culture of the UK and the USA.
Yes, like I say, the class system, and the typical engineer's strongly expressed desire to dress scruffily and generally nonconfom, disregard hierarchy and so on. There's no reason that software professionals shouldn't be on a par with lawyers and accountants, the work is similar enough (describing the current and desired states of complex systems in very precise terms, and creating finely detailed plans for getting from here to there).
> describing the current and desired states of complex systems in very precise terms, and creating finely detailed plans for getting from here to there
What a beautiful and elegant description of software engineering!
What do you think will happen? Will the engineers earn more than the managers, or will the managers salaries go up just because the engineers earn more?
No, you will have managers crying about a talent shortage, and engineers wondering why they get paid so much less than lawyers, accountants and doctors (all of whom count as "white collar").
These "intangibles" can still have a value assigned. Each integration bug eliminated by an improved build process can have a cost assigned to it by using the average time and money cost of previously fixed integration bugs. Example: "Each integration bug costs 1hr of senior dev time at $100/hr fully loaded and 8hrs of junior dev time at $50/hr. The new build process produces X fewer integration bugs per month, for a savings of X*$500 per month."
"Transforming" the sales numbers should also be measurable. Example: "Before, salespeople were closing x% of deals and missing scheduled followup on y% of contacts. Now (x+5)% of deals close and only (y/2)% of contacts are mistakenly dropped."
a 25% raise is unlikely next year, sounds to me that this was more of a salary adjustment than a raise which are typically between 3-9%. At your salary level it's not uncommon to have adjustments to bring you in line with others in your team. Possibly they started you low to see how it would work out.
Professionally, only about 4 years, also a year as a sysadmin and a few in the Air Force a while back. That's why the peanuts. I'm not the most amazing programmer ever, but I am pretty good. I also have business sense and the ability to talk convincingly to non-technical people.
These things ultimately mean much more to a company, at least my company, than years at firm. I'm also constantly pushing myself to build more skills, not just programming, but also social skills too. I've noticed the longer I do this, the more people are willing to listen to and value my input. My company hierarchy is very flat for one that does $40 million in revenue. I see my CEO whenever he's in the office, his office is right next to my workspace.
It's a case of, sure, I could go somewhere and get a $X0,000 raise and finally check that six figure salary box, or I work here towards middle / upper management and reach that goal in just a few years and get a $X00,000 raise. I'm comfortable right now, no need to make a decision right now, I don't hit two years here until July anyway. If by then it doesn't look like the vision I have for my career here is really viable, then sure I'll start looking.
I started with a fairly low salary of ~50k USD in my first job in 2009, mostly because I screwed up salary negotiations. I've changed jobs twice since, and roughly tripled my salary.
> I'm not the most amazing programmer ever, but I am pretty good. I also have business sense and the ability to talk convincingly to non-technical people.
If you can deliver at all, you are probably better than most programmers out there. Talking to non-technical people is an awesome skill in its own right.
Yes, my asking about how many years you've been working was just as a rough proxy.
If you want, you can shoot me an email (see profile) for some more in-depth chats. I'm interested to see how typical my trajectory is. I don't think I did anything extraordinary, but most people I talk to seem to be getting inferior results.
I'm not sure pointer concepts are very difficult, pointers might confuse people that didn't grow up with assembly language, but they really aren't very hard to understand and they are also less and less relevant. Over the years the abstraction level increases, it's far better to teach people to continue computer science to the next 21st century level, not go over stuff from the 70's again that they will likely never use. The breakthroughs in CS coming very likely won't be written in C (or assembly for that matter).
You cannot write effective code in Java, Python, or C++ without understanding the difference between references and values. You can certainly stick to higher levels of abstractions - most functional languages do a good job of that, especially ones like Haskell that emphasize immutability and value-only semantics - but pointer concepts are absolutely relevant to the industry-standard languages.
I kind of feel like as long as we have imperative programming languages, pointer concepts will be useful. I mean, that's basically what references are.
Apple are just pissed they didn't think of the hamburger menu first. This is terrible advice, the are understood by all and the few people that don't know where this mysterious control will take them can just click it and see. It's not like it's the rm -rf button.
Apple doesn't usualky care if someone else did something first though. If they decided the Hamburger Menu works well in particular use cases, and want to use it in an app of theirs at some point in the future, they'll just drop it into a new iOS SDK and hope everyone forgets about this advise.
it's hardly java's fault he's looking at a stack frame and not seeing the variables that belong to a different stack. This is simply a matter of selecting a frame prior to the forEach.
Eclipse's debugger can be configured to show a refined output. The controls are in the upper right in the Debug Perspective. Programmers who make applications are not programmers who write IDE's. If I'd noticed this I don't know if I'd recognized it or dug into it more to understand it but a snarky comment like the one I replied to is not appropriate or helpful.
I disagree. The lambda expression allows him to use variables outside of the stack frame, why shouldn't the debugger also be able to show those same variables?
you'll also notice some editorializing the topics (venture -> venture capital)
the lda features are already grouped, that's exactly what an LDA does, however, translating a group of words into a "summary" (whatever that is) is non trivial. You'd find need to define what you're looking for. A visual summary for example might for example be a word cloud, another might be the use of ontology tagging if you consider those a salient summary.
not a big surprise, they've all but completely disappeared from sight around S. Another Segway, but I doubt Google were ever serious about Glass, it was a demonstration of Google as committed to being a futuristic hi tech company.
The problem with the product is that people like the compartmentalization of the smartphone, you take it out of your pocket to take a photo, nothing surreptitious. And to be honest, the smartphone just does a lot more. This is going to be the challenge that the Apple Watch will also face, it competes with the smartphone for your attention and has to add enough additional value to justify the product segment.
Meanwhile, it's no big deal, products come and go and some end up with much smaller target customer base, although I suspect Glass is (as Segway was) being considered for a few specific markets but over the coming year or two will just vanish only to be revisited in a decade but with holographic projection (a la R2D2) and streetview-like surround-camera and built in plethora of biometric sensors that all feed into the big post-Singularity GoolgleBrain to provide it's eyes, ears and voice...
