Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Call Yourself a Programmer, and Other Career Advice (2011)

kalzumeus.com

Post reply on HN
Print view View original

161–170 of 316 posts

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#161

Post by bhldev »

scarface74 wrote: post #155
bhldev wrote: post #121

Earlier quoted context omitted.

I notice this a lot on apps in the subway (who doesn't) and the app just dies A lot of problems in life can be simply avoided this is no different... If you're getting that tiny last bit of differentiation because you're 90% market share and you can afford to hire people to solve that exact specific problem then great. But that isn't most places. Most apps would do better to 100% avoid the problem and just say "No In…

And you’re kind of demonstrating my point - the difference between people who think it’s an easy problem and the proportion who have experience. Enterprise mobile apps aren’t about the apps you download from the App Store. Usually they are distributed using an on-site mobile device management system. 1st use case: I worked for s company that wrote field service applications for ruggedized Windows mobile devices. Some…

It's not an easy problem. It's a database concurrency issue and well beyond the skillset of most mobile devs. Database isn't even a required course for a compsci degree it's usually an elective.

My point is the problem you think you solved, you didn't and it will break under dozens of scenarios. Maybe the clients are happy and they think it works but you just haven't encountered the case where data goes missing or overwritten.

In other words what I am saying is it is wrong and hard to know it is wrong unless you directly attack it. The word "enterprise" is an euphemism for low cost and potentially low quality. It's a buzzword. I wouldn't take an Enterprise mobile developer over a B2C mobile developer just because of the word enterprise.

Not everything in the world should exist that leads to 737 Max. The word "sync" has implications way beyond the concerns of a mobile developer.

So I call bullshit; the fact the industry does it, that everyone does it, that you consider "real" mobile devs to require it, that customers want it doesn't mean it is a good idea or that it's mathematically or scientifically sound. It may cover most cases and nobody may notice the problems except once in a blue moon but that doesn't make it right because operational systems need full data integrity.

The correct way to handle such a request is not to "sync" but to collect data push it to the backend and let the backend sort out the mess. Not "sync" by whatever stretch of the imagination no matter what cottage industry or cult beliefs have been born of it.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#162

Post by sireat »

dejawu wrote: post #124

Sure, this post might objectively get you to a higher paying software job, but good God I hope I never start seeing the world like this guy or ever have to work with people who do. Am I really reading the same article as everyone else? The one I'm reading is filled with these sociopathic gems: > Add revenue. Reduce costs. Those are your only goals. > You’re in the business of unemploying people. If you think that is…

Patrick (patio11) had a dream of working in Japan and a belief in a rational just world.

That dream and belief was shuttered when the reality of being an overworked gaijin for an uncaring zaibatsu settled in.

His ticket out proved not to be Bingo Card Creator directly but the articles he wrote on HN (and elsewhere) to boost the SEO for BCC.

Not knocking him in any way, I would probably be still stuck in Japan, falling asleep at late night metro every night.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#165

Post by enraged_camel »

srazzaque wrote: post #93
arbuge wrote: post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

I agree with you, it's not how technical people are hired. But, I think it's entirely necessary in certain contexts, once we realise the software world is bigger than just Web. Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master. So I'd be inclined to add disclaimers to the idea that "after 6 to 12 months nobody will ever notice". This might b…

>>Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master.

Here's why I think this is sometimes a false dichotomy: going from Ruby to Python will be relatively easy. Going from Ruby to Haskell, on the other hand, will involve not just learning Haskell the language (syntax etc.) but also new paradigms and entire new ways of thinking.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#166

Post by guywithahat »

amirathi wrote: post #60

This is fantastic practical advice for software engineers early in their career. Here's some more based on the common pitfalls I see, - Don't apply to 50+ companies at one go thinking only a % of them will call you. Choose ~5 companies, do a lot of homework about their business & write to key people at these places telling in ONE paragraph what you can do for their business. If it fails, choose next ~5 and so on. - O…

How would one do this though? Should I find these people on LinkedIn and message them? Should I try to find their email? I’m applying rn and I’ve heard this advice before, I just don’t know how it could be implemented in practice.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#167

Post by JMTQp8lwXL »

arbuge wrote: post #41

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t be…

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems.

The stack an engineer has experience with can be one indicator of the areas they excel in.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#168

Post by vlunkr »

scarface74 wrote: post #46
elif wrote: post #32

I call myself a programmer to avoid people thinking I want to be a manager or spend my days in meetings. I want people to expect 90% of my output to be code. If this is good for a career? Don't know don't care. It's what I do and enjoy, and there are many slippery slopes to not coding and becoming rusty, and ending up on the M train by default.

How do you know what to code or whether you should even be coding at all if you aren’t willing to spend the time knowing the business and the customers?

This shouldn’t be a problem in a business with well defined roles. Boss/manager says customer wants x. I don’t care why they want that, and I may even think it’s dumb, but I can make it happen. After all, I get paid to solve problems with code, not interpret customer requests.

Re: Don't Call Yourself a Programmer, and Other Career Advice (2011)

#170

Post by scarface74 »

bhldev wrote: post #161
scarface74 wrote: post #155

Earlier quoted context omitted.

And you’re kind of demonstrating my point - the difference between people who think it’s an easy problem and the proportion who have experience. Enterprise mobile apps aren’t about the apps you download from the App Store. Usually they are distributed using an on-site mobile device management system. 1st use case: I worked for s company that wrote field service applications for ruggedized Windows mobile devices. Some…

It's not an easy problem. It's a database concurrency issue and well beyond the skillset of most mobile devs. Database isn't even a required course for a compsci degree it's usually an elective. My point is the problem you think you solved, you didn't and it will break under dozens of scenarios. Maybe the clients are happy and they think it works but you just haven't encountered the case where data goes missing or ov…

So you’re saying “it’s not a good idea” to have software that actually fulfills the need? The mobile app that doesn’t work in the majority of use cases to solve the problem that it was meant to solve is useless.

And yes “the problem” we solved, a mobile app that could route field technicians dynamically at a level of quality we needed we did solve.

The word "enterprise" is an euphemism for low cost and potentially low quality. It's a buzzword. I wouldn't take an Enterprise mobile developer over a B2C mobile developer just because of the word enterprise.

Again this comes from someone who thinks they have experience versus someone who does have experience. Did you read the link I posted about the industry required rules for repairing railway cars? That isn’t even the entire regulation. If the typical B2C app doesn’t work, oh well. For the railroad industry, if you don’t submit your railcar repair just right - it gets rejected either by the interchange or the customer and you can only submit your invoices and rebuttals once per month.

The correct way to handle such a request is not to "sync" but to collect data push it to the backend and let the backend sort out the mess. Not "sync" by whatever stretch of the imagination no matter what cottage industry or cult beliefs have been born of it.

How well does “one way server syncing” when you’re a field tech doing routes and the customer calls customer service and cancels one of your routes while you’re in the truck? How well does it work when your back end system needs to calculate where each truck is on the road and needs to re-assign routes on the fly? How well does it work when one tech needs a part and they need to know where the parts are based on what other techs have already been at the warehouse and now they have the part? But wait, they went to the customer’s house and found that they don’t need the part at all and it’s available on the truck a mile away? All of this involves dynamic two way syncing...

Again, the difference between someone who has real world experience and someone who thinks that because their Twitter app doesn’t need to work in the subway nothing does.

Post reply on HN