I feel the need to take a different approach to this week's rant. I think someone needs to defend teachers, for a number of reasons. Obviously this is probably out of place on devRant but it is a kind of rant against those who think they know everything and have nothing to learn.

1) Teachers are not industry specialists. They do not spend their lives keeping on top of the latest framework or project management methodology or code management tool. They are educators and that brings its own set of out of hours challenges and training exercises.

2) They have a course to teach and have probably used the same one for quite some time. Years probably. They (should) teach the fundamentals of programming not a particular language or syntax or quirk. Those fundamentals don't really change. Logic, problem solving, precision, structures, etc.

3) They need to provide a course which will cater for different skill levels. There are always class members who are bored because it's too easy and others who struggle in any subject.

4) Teaching is like any profession - there are really, really good ones, OK ones and there are shit ones.

5) They have probably never developed a detailed project or solution in their lives. They don't know the pitfalls and challenges that teams face in this kind of environment. Should they - maybe. But the probably don't.

I think that's all... I'm not a teacher (although I did fancy the idea at a time) but just feel they get a rough ride sometimes (particularly on here).

The solution for this one isn't nearly as amusing as the journey.

I was working for one of the largest retailers in NA as an architect. Said retailer had over a thousand big box stores, IT maintenance budget of $200M/year. The kind of place that just reeks of waste and mismanagement at every level.

They had installed a system to distribute training and instructional videos to every store, as well as recorded daily broadcasts to all store employees as a way of reducing management time spend with employees in the morning. This system had cost a cool 400M USD, not including labor and upgrades for round 1. Round 2 was another 100M to add a storage buffer to each store because they'd failed to account for the fact that their internet connections at the store and the outbound pipe from the DC wasn't capable of running the public facing e-commerce and streaming all the video data to every store in realtime. Typical massive enterprise clusterfuck.

Then security gets involved. Each device at stores had a different address on a private megawan. The stores didn't generally phone home, home phoned them as an access control measure; stores calling the DC was verboten. This presented an obvious problem for the video system because it needed to pull updates.

The brilliant Infosys resources had a bright idea to solve this problem:

- Treat each device IP as an access key for that device (avg 15 per store per store).
- Verify the request ip, then issue a redirect with ANOTHER ip unique to that device that the firewall would ingress only to the video subnet
- Do it all with the F5

A few months later, the networking team comes back and announces that after months of work and 10s of people years they can't implement the solution because iRules have a size limit and they would need more than 60,000 lines or 15,000 rules to implement it. Sad trombones all around.

Then, a wild DBA appears, steps up to the plate and says he can solve the problem with the power of ORACLE! Few months later he comes back with some absolutely batshit solution that stored the individual octets of an IPV4, multiple nested queries to the same table to emulate subnet masking through some temp table spanning voodoo. Time to complete: 2-4 minutes per request. He too eventually gives up the fight, sort of, in that backhanded way DBAs tend to do everything. I wish I would have paid more attention to that abortion because the rationale and its mechanics were just staggeringly rube goldberg and should have been documented for posterity.

So I catch wind of this sitting in a CAB meeting. I hear them talking about how there's "no way to solve this problem, it's too complex, we're going to need a lot more databases to handle this." I tune in and gather all it really needs to do, since the ingress firewall is handling the origin IP checks, is convert the request IP to video ingress IP, 302 and call it a day.

While they're all grandstanding and pontificating, I fire up visual studio and:

- write a method that encodes the incoming request IP into a single uint32
- write an http module that keeps an in-memory dictionary of uint32,string for the request, response, converts the request ip and 302s the call with blackhole support
- convert all the mappings in the spreadsheet attached to the meetings into a csv, dump to disk
- write a wpf application to allow for easily managing the IP database in the short term
- deploy the solution one of our stage boxes
- add a TODO to eventually move this to a database

All this took about 5 minutes. I interrupt their conversation to ask them to retarget their test to the port I exposed on the stage box. Then watch them stare in stunned silence as the crow grows cold.

According to a friend who still works there, that code is still running in production on a single node to this day. And still running on the same static file database.

#TheValueOfEngineers

dev, ~boring

This is either a shower thought or a sober weed thought, not really sure which, but I've given some serious consideration to "team composition" and "working condition" as a facet of employment, particularly in regard to how they translate into hiring decisions and team composition.

I've put together a number of teams over the years, and in almost every case I've had to abide by an assemblage of pre-defined contexts that dictated the terms of the team working arrangement:

1. a team structure dictated to me
2. a working temporality scheme dictated to me
3. a geographic region in which I was allowed to hire
4. a headcount, position tuple I was required to abide by

I've come to regard these structures as weaknesses. It's a bit like the project management triangle in which you choose 1-2 from a list of inadequate options. Sometimes this is grounded in business reality, but more often than not it's because the people surrounding the decisions thrive on risk mitigation frameworks that become trickle down failure as they impose themselves on all aspects of the business regardless of compatibility.

At the moment, I'm in another startup that I have significantly more control over and again have found my partners discussing the imposition of structure and framework around how, where, why, who and what work people do before contact with any action. My mind is screaming at me to pull the cord, as much as I hate the expression. This stems from a single thought:

"Hierarchy and structure should arise from an understanding of a problem domain"

As engineers we develop processes based on logic; it's our job, it's what we do. Logic operates on data derived from from experiments, so in the absence of the real we perform thought experiments that attempt to reveal some fundamental fact we can use to make a determination.

In this instance we can ask ourselves the question, "what works?" The question can have a number contexts: people, effort required, time, pay, need, skills, regulation, schedule. These things in isolation all have a relative importance ( a weight ), and they can relatively expose limits of mutual exclusivity (pay > budget, skills < need, schedule < (people * time/effort)). The pre-imposed frameworks in that light are just generic attempts to abstract away those concerns based on pre-existing knowledge. There's a chance they're fine, and just generally misunderstood or misapplied; there's also a chance they're insufficient in the face of change.

Fictional entities like the "A Team," comprise a group of humans whose skills are mutually compatible, and achieve synergy by random chance. Since real life doesn't work on movie/comic book logic, it's easy to dismiss the seed of possibility there, that an organic structure can naturally evolve to function beyond its basic parts due to a natural compatibility that wasn't necessarily statistically quantifiable (par-entropic).

I'm definitely not proposing that, nor do I subscribe to the 10x ninja founders are ideal theory. Moreso, this line of reasoning leads me to the thought that team composition can be grown organically based on an acceptance of a few observed truths about shipping products:

1. demand is constant
2. skills can either be bought or developed
3. the requirement for skills grows linearly
4. hierarchy limits the potential for flexibility
5. a team's technically proficiency over time should lead to a non-linear relationship relationship between headcount and growth

Given that, I can devise a heuristic, organic framework for growing a team:

- Don't impose reporting structure before it has value (you don't have to flatten a hierarchy that doesn't exist)
- crush silos before they arise
- Identify needed skills based on objectives
- base salary projections on need, not available capital
- Hire to fill skills gap, be open to training since you have to pay for it either way
- Timelines should always account for skills gap and training efforts
- Assume churn will happen based on team dynamics
- Where someone is doesn't matter so long as it's legal. Time zones are only a problem if you make them one.
- Understand that the needs of a team are relative to a given project, so cookie cutter team composition and project management won't work in software
- Accept that failure is always a risk
- operate with the assumption that teams that are skilled, empowered and motivated are more likely to succeed.
- Culture fit is a per team thing, if the team hates each other they won't work well no matter how much time and money you throw at it

Last thing isn't derived from the train of thought, just things I feel are true:

- Training and headcount is an investment that grows linearly over time, but can have exponential value. Retain people, not services.
- "you build it, you run it" will result in happier customers, faster pivoting. Don't adopt an application maintenance strategy

/rant

Today is Day Two of my Dev Ops Internship.

The only tasks I have been assigned today is GDPR compliance training, which I did not realize could be stretched out into so much repetitive detail.

I also sat in a meeting with a dev who committed his artifact builds to git and now needs us to remove them for him.

Also, I keep getting called Dylan. My name is not Dylan.

Design your system that it doesn't need user training at all. Make it obvious.

Today spent 20min in a senior android dev interview debating an ex backender CTO about the importance of final classes where he tried to pull out some sort of perfect answer from me about it. Ironically this is the same CTO who failed managing a previous android contractor who was supposed to rewrite old app and ended up with an even shittier new app in 6 months of time. Now they are insecure and are looking for a new contractor who will be micromanaged this time.

But hey I guess he knows the importance of final classes. Some CTO's need a reality check and at least some business training, because your perfectly written app is useless if it doesnt fulfill business needs.

Their app is based on heresdk and built around navigation. The biggest bottleneck is that it works shitty on low end devices so their competition solved this problem by using a whitelabel rooted tables with a custom ROM wher u have full control over hardware, permissions and battery management. However this startup thinks they can build a perfect navigation app which will work perfectly on all devices while at the same time while also relying on a poorly optimized navigation sdk. Poor initial strategy I'd say and they didnt learn from previous 2 failures, now they are searching for the next savior android contractor who will have to solely implement evrything.

Laravel being easy to use is far from a strong point. "Easy to use" is a cool thing for pro developers who know what's going on under the hood and don't wanna write the same thing a hundred times.
It should translate into good developers being able to work immediately, not in bad developers getting away with whatever without getting even a slight warning just because the framework itself accepts whatever weird crap you can come up with while you're training.
But that's what it became: a free for all for every noob out there. You find yourself working with a slow application (and by "slow" I mean "slow even by Laravel's standards", which are fairly low), and as soon as you look what's going on you find someone decided to load a hundred thousand middlewares, queries optimized like ass on top of Eloquent, and the whole application breaks as soon as you just run config:cache to try speeding it up a little bit, because env-ing your way out of whatever problem is so quick. Easy to use needs to be there for pro developers; give such a tool to a newbie, you end up with a maintenance nightmare

I think it would be nice to see less contracts with those companies which only have in mind barebones training and profit. That kind of relationship between institutions drops the standards and it's expensive af. Those who sells cheap computers and bad software and charges more than ten time their value, those with enough power and influence to bend every single rule...

That kind of companies shapes the industry according to their needs, and will never give a shit about anything but the next semester. They teach you to be just a bit more than a user, they charge you like if they were really teaching science.
You end up full of debt, self taught on the technologies that matters, and accepting jobs on projects as outdated and mediocre as the "educational plans" you paid thousands for. And all that just to get a piece of paper signed by a stranger who doesn't care about you, and enjoyed by a corporation which wouldn't even consider to hire you because they know what they sold to the education department.
Fuck this, today I hate it all.

Backstory:
Got into a "fellowship" program with a community. They provide the templates for their website and we have to work and edit it to suit their needs. Now with a bunch of colleagues who have also been selected I finished the first part (i.e building the site) now they are training us to use their APIs and include it in their site and build the backend.

All of this I am doing without pay and according to them the benefit I get is "understanding how the industry works" and that "it will benefit us" with a promise that if we finish their sites, companies and startups will give us paid internships. I already know how APIs function and I'm not that invested in frontend stuff.

Jumping to the main question:
Should I continue here or should I quit?
Is this how the tech industry works?
Also an explanation to your answer will be great too!