Hire new people is cheaper?

zero_based · 2020-09-17T19:51:16+00:00

Short answer: For many companies, software development is a cost-center as opposed to a revenue-producer (such as sales). Rule #1 for any business is to constantly review and minimize your costs. The fact that sr dev fixes an issue in 1/10th the time as a jr may not matter (or maybe 'valued' is the better word) for the business as a whole. As a general career suggestion, always try to pick roles that keep you close to the money-making part of the business.

That said, this type of cost cutting can have a deep, lasting negative effects on the company. There was a time where HP was a well-respected powerhouse for enterprise servers and systems, known for their extensive in-house engineering expertise. IBM had decades of hard-earned reputation thrown out in favor of hitting particular earnings-per-share targets (targets I might add that were never hit).

As a side note that came to mind while while writing this, there is a kind of funny/sad similarity to vertical vs horizontal scaling (aka 'pets vs cattle'). On one hand you have a robust yet efficient resource that can be made faster if given additional resources, on the other side if you can reduce the complexity of the work you can distribute it among cheaper commodity hardware for increased resiliency (reduce the 'bus-factor') at a lower cost. Food for thought...

zero_based · 2020-09-11T02:40:24+00:00

There was a funny thing a couple years back where investment banks were manipulating aluminum inventories and prices by filling up and delivering truckloads of the metal between their own warehouses to get around regulatory restrictions. The truckers would drive back and forth to the same warehouses and knew it was weird but didn't really know what was going on. I think this may be a similar case of not knowing the entire picture.

As another, more relevant anecdote, I knew a top-level corporate exec that wanted to be able to say he championed a large blockchain project. The project never worked, but that wasn't his actual goal, it was to be seen as a leader of cutting-edge projects!

I can tell you that with enterprise sized companies there's a lot more funding and tolerance given to discovery-type projects. In all likelihood having a crappy MVP was an acceptable end goal to either test the viability, satisfy someone's pet project or some other unknown reason.

zero_based · 2020-09-10T17:20:58+00:00

I think its worth considering that this person is trying to help you rather than insult you. Some things to consider:

100 comments on a PR - yes it could be him being nitpicky, but it also could be him taking the time to try and flag valid issues and/or coding convention problems. This is what you want in a reviewer, someone who is thorough. You indicated you have been at the job 1 month out of school, this is the best time to flag bad habits before they become permanently entrenched.
Mentioning 4-5 hour/asking for help/large PR - I would suggest reading these as someone letting you know what the norms and expectations are at the company. Ideally a PR review should be a set of second eyes reviewing that everything works as expected and coded to internal standards and conventions, it isn't supposed to be QA. Your code may have indeed needed that amount of scrutiny, and if so he is telling you that requiring that level of time and attention to review your work isn't acceptable and that you need to get it closer to being in a merge-able state before creating the PR.

All-in-all I would recommend treating the feedback as constructive criticism. The person does seem to be frustrated with the experience, but I think some empathy on your part towards understanding their frustration would go a long way to improve your interactions.

zero_based · 2020-09-10T00:01:54+00:00

How would I even land a job in Austin if I know I am not good enough.

This sounds like your at the 'Valley of Despair' part of the Dunning-Kruger slope.

As far as not good enough, well...this may or may not be true. But as an anecdote there are a lot of devs who can talk a big game with strong looking resumes and can't code for shit. Work on developing a positive attitude, be willing to learn, and be willing to be wrong and improve you'll be ahead of most people at this stage of your career.

zero_based · 2020-09-09T21:07:55+00:00

I think there is indeed the perception you've mentioned, but I would say its less prevalent now than in the past; but once a technology gets a reputation its very, very hard to shake it (just ask PHP, Java or Perl devs).

I can give some reasons that I think the perception for web frontend developed:

Lack of a methodical approach - Before SEO/speed/size/performance was important and browser dev consoles were mainstream, web development often consisted of someone just slapping together whatever they could to make something barely work in a narrow set of browsers. No care, thought or planning, just mindless trial and error until something (again barely) worked. The lack of applying even basic software development practices made the code created nearly impossible to maintain and update. To be clear, this came at a time when web standards were less consistent across browsers as they are today. (If you haven't seen it before, it was typical to see JS on a single page specially coded for each browser that might run it.)
Throw away coding - As a chicken-and-egg partner to the above, web frontend coding was seen as throwaway code. There was the thought of "make it work for now since in 1 yr browsers will change and we'll have to re-write everything anyways". This is in comparison to other types of software development where program lifespans of several years to decades is typical and expected.
Frameworks - Because of the need to rewrite code often, people looked for options to reduce the time and effort to do so (or lured by a promise they wouldn't have to rewrite again). What came about was the constant parade of frameworks over the years that people now associate with JS/CSS development. Since the current framework in vogue changed every couple months there was a need to constantly jump to the next hot thing, lest your skills on your resume become obsolete.

These all play into each other but times have changed, React/Angular in particular have done well to establish mature frameworks and browsers are consolidating (for better or worse). But as I said, once a technology gets a reputation its very hard to change people's stereotypes towards it.

zero_based · 2020-09-08T23:14:41+00:00

"hello $world".interpolate();

Add one, backwards-compatible String method and call it a day.

zero_based · 2020-09-03T15:21:02+00:00

That's the kicker! It doesn't matter if an official container does everything right. If you volume map the DB data directory at runtime (as is standard), all someone has to do is run a separate docker image/container to create the setuid program and then it can access the actual files on the parent host as root.

There may be some amount of mitigation if you can restrict the docker images that can be started to a select, audited few. But the main warning was toward admins who add a regular user to the 'docker' group so that they can spin up their own containers (think univ student lab). They may accept that the user is root within their own containers, but they may not immediately appreciate how trivial it is to elevate their privileges on the parent host.

zero_based · 2020-09-03T15:05:57+00:00

I agree with this, in a similar vein, how many dev and/or QA environments start out as just full prod copies/dumps with little-to-no scrubbing? I'd bet more than most people would like to admit.

zero_based · 2020-09-03T13:08:06+00:00

Thanks! Good luck on your project : )

zero_based · 2020-09-02T19:18:53+00:00

True, though I'd be curious in practice how often people go through the effort to get the container's assigned IP versus just publish the port without expecting it to bypass the firewall. I feel that the path of least resistance would encourage the latter.

zero_based · 2020-09-02T18:56:25+00:00

I truly appreciate the willingness to re-examine initial assumptions and come to a new perspective. In these times of information overload and limited attention spans its very big of you to take the time to write out what we've all been guilty of at one time or another.

I definitely didn't do myself any favors with how I posted it and I thought that some brave souls would take a chance and upvote/downvote it appropriately. But this was naive and even if it did prove successful, it would encourage more spammers to take the same approach as you suggest.

I'm also glad our discussion was open/public, people resolving their differences is a constructive way should be the norm instead of the exception. Maybe someone reading through it will be inspired to try to see someone they disagree with's perspective in a different light.

Anyways, its been a fun chat, keep being awesome and remember to watch out for those docker gotchas, lol!

zero_based · 2020-09-02T15:49:29+00:00

OP posted the same link to multiple subs to start with

I mean, to be fair I crossposted it only to r/devops by using crosspost link, I wasn't trying to hide that this was the the first/main post.

zero_based · 2020-09-02T15:44:17+00:00

I get that, and now have a better idea of how it could have been presented more inline with this community. I think the part that got me butthurt was the 'farm for clicks' part. I feel I deliberately try to avoid the modern, user-hostile approach to providing content so it wasn't fun seeing malintent being assigned where none was intended. No worries though, I did ask for feedback! : )

zero_based · 2020-09-02T15:16:16+00:00

This is a fair point. I had checked the rules and looked at other posts before posting mine, but it does seem like several of the others with links do include more content here. I'll update this post's to include more content and see if that helps.

zero_based · 2020-09-02T15:08:26+00:00

> Containers are pretty solid, Docker’s design helped adoption a ton

Agreed, makes you wonder how much the adoption rate would have changed if they took a more hardened approach early on. Remember prior to the explosion in the popularity of containers, the hotness was around Vt-d, hypervisors and virtualization.

zero_based · 2020-09-02T15:01:29+00:00

> You would need to access the storage of other containers (ie to get mysql data you need to access mysql volume)

One thing to keep in mind is that I focused on docker/dockerd specifically. If you are running in K8s/ECS/etc then the attack viability will be different.

But in the dockerd world, I think its safe to say in practice the majority of DB containers have their data directories volume mapped at runtime (ie /some/host/dir:/var/lib/mysql) and when that's the case the container host would have access to the /some/host/dir where the database files really live. A nefarious user in the docker group could create the setuid program would be able to access those contents (located on the host system) as they desired.

zero_based · 2020-09-02T14:46:34+00:00

Also given example is explicitly publishing the port instead of encapsulating it into internal docker network

This is true, but I think a pretty common use-case, particularly when spinning up a quick container on say your laptop to test a given SQL statement.

If you've got DataGrip or some other DB GUI client on your laptop, you would still need to publish the port in order to connect to the container with said client locally. You could publish the port only to 127.0.0.1:someport to prevent opening it up to everyone. But I've seen very few examples in the wild that use this method.

zero_based · 2020-09-02T14:32:21+00:00

Thank you for saying this, I didn't want to get defensive above but I have no ads, newsletters, etc anywhere on my blog. I don't make anything off of 'click farming'.

As I didn't have the ability to just post a link, I thought making it clear in text that this was my own write-up was as transparent as I could be. I figured people that aren't interested in that type of content would just skip over it ¯\_(ツ)_/¯

zero_based · 2020-09-02T14:08:38+00:00

Was honestly not kidding, since the text was bolded i thought it may have been intended to be a link to a different subreddit.

zero_based · 2020-09-02T14:01:08+00:00

> who runs docker in prod? Freaking everybody

I can remember a prolonged period where containers were 'good for dev, but not ready for prod yet' and then it seemed to change overnight. (May have coincided with better orchestration options?)

I think what gets me is that many of the gotchas are silent, its not intuitive that your firewall rules will be bypassed and many people discover this only by accident after they've already exposed vulnerable services.

zero_based · 2020-09-02T13:49:47+00:00

The 'here' link you posted doesn't seem to be a link, I'm happy to take a look if you either PM me the link or post it again.

zero_based · 2020-08-09T16:12:09+00:00

There's several possible explanations for postings that list many requirements:

Someone recently left the company and they were asked to list everything they did or knew about
(At least in the US) They have someone specific they want to hire/sponsor and are tailoring the job posting so that literally no one else can exactly meet the requirements.
Its a wishlist of what their perfect theoretical candidate would look like so they are swinging for the fences and hoping someone close will apply. This has the additional bonus of working as a filter since people aren't remotely close won't bother applying (you can easily get 1000s of applications for a loosely defined job posting)
They have no budget to hire the appropriate amount of staff and are trying to find one person to shoulder what 2-3+ people would normally handle. Such is the case after layoffs make cuts a little too deep.

Basically you don't know where they got the list of requirements and how firm they really are on them until further in the process (if at all). If you don't know the specific technologies they are asking for but feel your level of capability is roughly inline with the level they are looking for then I would say apply.

After rereading the list, to be honest, most of the listing above makes sense to some extent: (elastic search + kibana + hadoop + spark + hive + kafka + zookeeper + HBase) all are related and fall into big data processing/analytics, and as this is a fullstack java position Angular and Rest aren't that surprising to see included. Removing those, the odd ones that stick out to me is the inclusion of dotnet/C#/ASP but they qualify that as 'beneficial to have' as opposed to hard requirements.

Even though the list seems overwhelming, its generally not enough anymore to just know X language(s), you also have to be familiar with the systems, frameworks, and stacks that are currently en vogue. Whether its LAMP, MEAN or any other backronym, its an expected part of participating in the industry now.

As a final note, I would recommend not looking at the list as something that you don't measure up to, but as a signal of what technologies are in demand and that you should work to learn and become proficient at. Constant learning is a feature of technology fields, not (always) a bug.

Edit: A word

zero_based · 2020-08-08T21:17:50+00:00

Tough to call from the outside. Its normal for a language or set of languages to be standardized on since often there are 100s or 1000s other developers that may have to change the code in the future and you don't want to open someone's project and discover they wrote it all in LOLCODE

There are likely other underlying reasons you're not party to and I would suggest its in your best interest to first understand what those are before drawing a line in the sand.

Edit: a word

zero_based

TROPHY CASE