Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "this should happen more often..."
-
Some of these things have been probably mentioned already in some way, but I'd like to add my two cents nevertheless
I grew up in Germany and have been in the German school system for my whole "school career" and what I always missed was a computer/programming related subject. (A real one, not this thing where they teach how to use MS Office) Something that would have pushed me a bit more into this world of technology and programming way earlier, because I didn't know which possibilities I had. It doesn't happen often that I think that something is better in Slovakia but I have to say that in Slovakia they are teaching CS in standard schools from the age of 11or 12 I think. I don't exactly know what they teach there, maybe it's shit, but it's something at least. I know that most people swear on teaching themselves programming and all but there are people like me who struggle with that.
Then of course I'd like to see the teaching get better. They should teach the useful stuff and focus on practical experience.5 -
*follow-up to https://devrant.com/rants/1887422*
The burnt remnants of my ID card's authentication information, waiting for the wind to come pick it up. It's stored in my password database now and committed to my git server, as it should be. Storing PIN and PUK codes on paper, whatever government cunt thought thought that that was a good idea...
If you've got identification papers containing authentication information like PIN and PUK codes, by all means add them to your password manager (if you're using Linux, I'd like to recommend GNU Pass) at once and burn the physical version. There's no reason why you'd want those on paper, unless you store your passwords on a post-it too.
At least that's as much as me and possibly you as citizens can do. Our governments are doomed anyway, given the shitty security policy they have, and likely the many COBOL mainframes still in use today. Honestly, the meddlings of Russia with the US elections doesn't seem too far-fetched, given this status quo. It actually surprises me that this kind of stuff doesn't happen more often, given that certain governments hire private pentesters yet can't secure their own infrastructure. -
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
/rant2 -
Pulled into an 'emergency' meeting with a group of web designers deeply concerned a particular service wasn't going to meet all their requirements.
DevA: "For each page, Its going to be A LOT of work to retrieve all the data and store it's state. Every page load will require a round trip to the service."
DevB: "Yes, we aren't sure how the service should be changed to do what we need."
Mgr: "What is it not doing now? Doesn't the service already returns all the necessary data?"
DevA: "Well...um...its all the boolean fields. Some may be defaulted from the database or false because the user unchecked the box. We have to know which is which"
Me: "Why? Are you doing anything different in the UI? Checkbox will be true or false. What or who set that value is irrelevant"
DevC: "Well, it matters if the user didn't fill out all other other values."
Me: "How so?"
DevA: "Its matters because the values in the other fields. Its going to be A TON of work to figure out."
<mgr goes to the white board>
Mgr: "Lets map this out...what fields are you needing to trigger the state on?"
DevA: "Um...uh...the 'Approved' field...and um...'OK to Contact' field"
Mgr: "Just those two?"
DevA: "Yea..um...there are other fields, but whether or not to show the edit box depends on those two."
Me: "The service already returns data, you only have two fields to check? I don't see a need to change the service at all."
DevA: "Returning all that data, we are going have a serious scaling problem. We'll be hitting the service A LOT. All that javascript could cause performance problems too"
Me: "How much data are we talking about? Name, address, couple of booleans?"
DevA: "I have to serialize the data. All that logic is going to be reeeaaallly complicated. It might be better if the service returned only the data I need."
Me: "$64,000 question, how often is this feature going to be used on the web site? Maybe once? Few hundred a week?"
Mgr: "We have no idea. A lot of the data will be pre-populated and we're only sending out a few thousand invitations. More around the holidays...but honestly, not very many."
Me: "Changing that service only for this particular area of the web site isn't going to happen. Changing the UI is the only course of action."
DevA: "Oh frack I can't wait until this project is over."
DevA...how the funck do still have a job here? You wasted about half-hour of my time with your cry-baby crap. Where is my hammer...no...no..don't go there...ahhh...thanks devrant. Prison sentence diverted.2 -
*class ends, close laptop*
Ten hours later (right now)
Me: 😶 can't remember why these unit tests failed... Let's run again and see why.
*build success, runs more test cases and tests, all builds fine*
Best feel ever 😎1 -
!dev
Should I be myself? A tougher question than is seems.
I’ve had major struggles, faced and conquered death, travelled the world, and live with highly functioning Aspergers and much more. Not boasting, just laying the background info.
With all of this it has led me understand, on a fundamental level, difficult truths that most people only understand upon death (if ever at all).
These lessons have had an unspeakable positive impact on my life and the way I approach things.
The problem seems to be that many of these truths are non-transferable, and that the process of even mentioning them makes most people uncomfortable.
I understand though, that the best truths in life are ALWAYS uncomfortable, and that there is great value in this for those who choose to accept it.
But should I risk putting these views into the world in a recorded manner?
This is something I struggle with all the time.
Currently, I do not use social media often (devRant excluded) because it is a cancer. Even when FB came out in high school I knew (without having the words to express it) that it was dangerous and cancerous to real life.
But it is such a powerful tool that it cannot be ignored.
———
For example. I moved across the country without a job, away from everyone I ever knew, to pursue the goal of starting my own software businesses.
The responses I got to this included...
“Won’t you miss you family and friends?”
“Why don’t you save for a while and go then?”
“Why don’t you look for a job and leave when you get one?”
“Aren’t you afraid of being alone?”
Most these seem like legitimate questions, and because I cared about these people I treated them as legitimate.
But my real opinion is that every one of those questions is based on either weakness, fear or stupidity.
- Of course I will miss my family and friends, why try to guilt me into sacrificing life for this!
- Why not wait for “the right time”, because the right time never comes. That is an excuse for failures to continue failing.
- Why not wait to get a job? Because that won’t happen if your not there! It’s just a fact, get over it!
- You are alone! You can try to fill your life with people and crap but in the end you are born and die alone! I’ve been dead and know this like I know the sun will rise.
But you see all of that above, for most people that stuff hurts. It seems insensitive and cruel.
It hurts because it is true.
————
That’s just a small sample of things.
The larger question still stand...
Should I be myself?
I really don’t know the answer and don’t expect one to come. Maybe someday I will find a way to do this.
For now I will continue to be what people expect me to be.
———
To end this I am gonna quote the rapper Pusha T and his new album...
“Remember Will Smith won the first Grammy?”
“And they ain’t even recognize Hova until Annie”
“So I don’t tap dance for the crackers and sing Mammy”
Maybe some day I will be able to stop tap dancing...
Maybe
https://open.spotify.com/track/...7