Dear future self,

Next time you're working on the project's routes, be sure that people don't have to be logged in to login.

It will make your life easier.

Regards,

Your past self that is tired to be this retarded.

Rails gems are like heroine. Addicting as fuck and dangerous when you stop using them.

Just the other day I was explaining user accounts explanations to a coworker when he asked me "what if for some reason you cannot use that package"

My brain froze for a minute trying to remember how would one go about doing that without devise.

Dangerous man.

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

So, I’ve been given the task of sorting the security out in an application plugging the holes and whatnot as to be honest it’s shocking haha. It doesn’t help that we automate security audits but that’s a different rant for another day.

We’re using devise for authentication (rails standard, ♥️ devise), we have no password resets through the login page, it has to be manually reset by ringing support, why who knows, even though it’s built into the gem and we allow the user to login using an username instead of an email because for whatever reason someone thought it was a bright idea to not have the email field mandatory.

So I hop onto a call with the BAs, basically I go that we need to implement password resets into the login page so the user can do it themselves and also to cut down support calls a ticket is already in place for it. So I go through the standardised workflow for resetting a password. My manager goes.

“I don’t think this will be very secure”

Wait.. what. Have you never reset a password before? It’s following the same protocol as every other app.

We go back and fourth and I said I’ll get it checked with security just to keep him happy.

The issue mainly is well we can’t implement password resets due to 100s of users not having an email on there account.. 🙃 so before we push this change we need to try and notice all users to set a unique email.

Updated the tickets. All dandy.

Looking at the PRs to see what security things have been done if any and turns out one of the devs in India has just written a migration to add the same default email to every user that doesn’t have an email present and yep it got merged. So I go revert the change but talk about taking a “we don’t care about security approach”.

Eventually we want to have the user reset their passwords and login using their email and someone goes a head and does that. Not to mention the security risk.

Jesus Christ I wonder why I bother sometimes.

Ticket: implement compression algorithm to crypto object x

Details: object to big, we must devise a way to compress it. A deflate algorithm should be added here, yada yada yada we did not have the time Yara yada...

Go see crypto provider's documentation... It has compression options... -_-

You lazy fucking stack overflow copy question dimwits!!! Jesus fucking Christ! This reached production like this shit, I've got clients complaining of the size of the payload because you are a bunch of lazy fucks who can't even read simple documentation!!!

I want to kill someone for wasting my time and patience... Don't call me for this kind of crap... I have better things to do!

I mean, the time it took you to write the ticket should suffice...

Today, I started a new project with Rails. I used always an own auth implementation, now I thought I'll give devise a try. Hell... the documentation is bad, really really bad. I really don't know why people are using this and don't write this by themselves. Anyway, I kicked devise and write it again by myself.

Copied from Plataformatec/Devise OSS project issue

"Right, I was following the wiki. I don't know how, but it magically started working. Not sure what did it, but it's working now! Thanks."

We know his struggle!

Hi fellow ranters, I humbly request your opinion on a matter.

I am a CS student in his last year of college, and currently developing a Node.js app as his final year project with a partner. The project has potential, and we've been at it for about three weeks, but the problem is that the more I code, the less I see myself doing Node in the future.

I was a total noob in CSS before starting the project, and I have learnt a ton in just 3 short weeks, but that has taken a toll on me, because I fell pretty far behind our schedule. However, for as much time and effort ad I have put in, my partner has put in a lot more (and he knows way more than me), thus increasing the gap.

My partner and I have (for the moment) different views on the amount of effort that we want to put in the project, since I see it as "slightly more than just another subject" (9-hr a week), and he sees it as a real passion project (endless hours). This could be due to the burnout of the first weeks, but I'm really not that excited about the project anymore, and I find myself thinking that I am wasting both of our time (I don't want to be dead weight), and that if I worked on a project that really made me passionate, such a compiler or a runtime environment, or a new programming language, I wouldn't mind putting in the hours that he does. Just to give more context, this whole project was his idea, and although I find it a great idea, and I know he is capable of building an amazing product, I am not sure whether I would be useful, or even if I want to be useful. Again, this could all be because of burnout.

Anyone has had such an experience?

TL;DR: I am working on a final project with a partner (it was his idea, and I found it interesting), but I think I would be happier switching to a project of my own.