These posters are the greatest truths😂

Heidi is hitting me with some harsh truths here.

When I'm watching a news story about the tech industry or software development, I always wonder if people in other professions also scream at their TV when their field of expertise is butchered with bad analogies and half-truths by reporters and anchors.

we in our clients' eyes and the truths

THE WORST PRANK ATTEMPT

If i remember true, it was 2012. april fool day..

me and my co-worker (we were the founders) decided to fool our members (we had a script's unofficial support forum). so, we did the plan. we register another account on march and wrote a few useful messages with it. help guys with that fake account (named as Root).

on fool day, we move the site to hidden folder (but didnt backup it) and added an index file as "hi, i am Root. you know me who am i. i hacked this site and deleted all dbs. cya later" (in turkish of course)

and we sit our chairs, began the watch our messages from facebook,skype,whatsapp etc..

we act like we are in trouble and we cant solve the problem.
at the same time, one of the our crew, decided to help us :D
so, he contact with our server's management crew. they dont know the fool too :)

server management looked up the situation without try to contact with me or my co. and we got an email from server like that
"hello tilkibey and impack, we just realized your site is hacked. so we delete your all ftp and db for safety. please contact with us asap"

we shocked and contact with them, explain the truths and request the recover our site (because we though they backup site before deleting all things). but they didnt backup it :(

so, we recover our last backup which is got nearly 10 days ago :(

I hate time.

Yes, that dimension which unidirectionally rushes by and makes us miss deadlines.

Also yes, that object in most programming languages which chokes to death on formatting conversions, timezones, DST transitions and leap seconds.

But above all, I hate doing chronological things from the point of view of code, because it always involves scheduling and polling of some kind, through cron jobs and queues with workers.

When the web of actions dependent on predicted future and passed past events becomes complicated, the queries become heavy... and with slow queries, queues might lock or get delayed just a little bit...

So you start caching things in faster places, figure out ways to predict worker/thread priorities and improve scheduling algorithms.

But then you start worrying about cache warming and cascading, about hashing results and flushing data, about keeping all those truths in sync...

I had a nightmare last night.

I was a watchmaker, and I had to fix a giant ticking watch, forced to run like a mouse while poking at gears.

I fucking need a break. But time ticks on...

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

Day 1 of a new semester in college. Our 50 yr old H.O.D is a guest lecturer of this new subject called "Industrial Management" (why its included in the syllabus of CSE degree i wonder) . As there were only 6 students , the guy went on like a drunkard telling life lessons :

1) only 20% of the people in a company are only working. Rest 80% of them are just using sugar coated words at the right place ; doing politics and taking credits of the others .

2) those 80% getting benefits are usually the bosses (and in his example, the senior deans and H.O.Ds buttering the administrative dept and director ) and the hardworking 20% are the Juniors or the new joiners ( and in his example, the latest recruited ,honest teachers. Makes sense why we have shitty teachers :/ ). They altogether make sucesses to the company(although its just those 20%hardworkers doing the actual job) . But at the time of salary everybody gets the benfit.

3) Its always perfect to throw blames at senior or junior. (explaining how a parent complaining about the poor study environment to director is made to think that it's only the fault of his own child. blames going from director to dean to HOD to teachers to your own child's mistakes.)

4) Being your boss's favourite is super important. He gave example as : 2 teachers meets him with 100% results and 100% reviews. One of them is a known asshole with 0 knowledge, who makes jokes and sexist comments during the class, gives free attendence and question papers before the exam{therefore 100%reviews} . But he is dean's great ass-licker . The other one is honest hard-working teacher with real reviews and results. So he says he shows their combine results to the director along with his own buttering and ass licking, gets a hike himself and permit to give hije to one junior teacher. And who would it give hike to? The ass licking asshole, because that's how it works. What about the honest teacher?what reply would he get? Simply, appreciations and sugar coated words : "thank you for working so hard. But you did not do anything new. You were only hired to DO hardwork and give good results"

( and i was like fuck? Like seriously? Because that is something resonating with what i once heard in my internship :"yeah you are developing nice and all good, but that's what you are expected to do. You were only hired to achieve results, and you did nothing new". So that's what we are missing? Ass licking?-_- )

5) He believed its important to "look working" than being "actually working" . Quoting an example from his days as a dev, he told a story about how he once worked on a project with deadline of 1 month . He was young and worked hard and in 2 days completed the complete project and accidentally reported success to boss instead of his seniors. The boss simply congratulated his team(seniors and him) and assigned them another project. Later that day , he got an ass-wipe scolding from his seniors that if he had kept his mouth shut, they would have simply watched movies and relax for next 15 days, and submit the project during the salary time to gain bonus attention.
He even gave his short mantra or principle for such situation "kaam ki fickar kar, fickar ka zickar kar, par kaam mat kar " (get worried and tensed about the work. Display your tention and worries to the world (esp bosses) . But don't work.)

And there were many other short stories like that.

Mann, i was about to shout " you corrupt asshole ", but one thing He just told us about the importance of being in boss's good books made me stop ( nd he is a fucking HOD, senior to teachers)

But hell he told some relatable truths. Make me sad about the job life.

Bloody Office politics :|

The source engine is interesting, because it has reached that stage of life where it's old enough to be remarkable-- in the sense that it could be called 'legacy', a sort of milestone in development practices and thinking, both in software, and design.

That said, a better look at it might be from the lense of *uses today*.

A lot of former source engine (SE) devs are now going to unity or unreal, I don't blame them.
But it's interesting to examine examples of games that haven't.

One such game is the freeware "No More Room In Hell". A couple online play throughs shows a wealth of well designed maps (and an even greater horde of shovelware maps, but hey, you take the good with the bad).

The age of the engine itself shows. Even in games like Left 4 Dead the engine's age can be seen. This, in some respects has been a drag, but also a blessing. Where other games could rely on their effects, shaders, and other tech, modders, map makers, and designers have had to rely on wit and creativity.

Enter "situated environments."

In an age where many people desire to travel, to go places, and have grown up doing the exact OPPOSITE, there is a great desire for variety of locations in games: not merely 'environmental' in the shallow sense of a 'theme' such as 'lava', 'tundra', etc. But in the sense of setting in general.

We want places that are both out of reach and yet familiar. Fire-fights happen in city streets. Apocalypses happen in neighborhoods where the skyline is both broken and at once something we know by sight. Open air markets, grocery stores, neighborhoods, all of these provide the back drops of popular games and series such as COD, Battlefield, The Last of Us, and yes, the example game, NMRIH.

I call this idea of 'familiar but out-of-reach level design', "situated environments", because familiarity with them, but *lack of real life experience* with them, on a day to day basis, allows people's expectations to fill in the gaps.

No one for example would argue the layouts of 7 Days To Die are familiar, but most of us don't spend all day in a junkyard or a high rise hotel.
So they *feel* familiar. Likewise with Skyrim, the villages and towns, both iconic and strange, our expectations formed by cultural inheritance, hollywood films, television shows, stories, childrens books, and yes, other games.

In a way, familiarity-without-real-in-person-experience is a shortcut for designers, one that lets them play with the player's head-space, the players subconscious idea of how a space and setting *should* work, what to *expect* out of the area, how to *operate* within the area. And the more it conforms to expectations, the more surprising an overdesigned element appears to be, rather than immersion breaking. A real life example of this is people's idea of chernobyl. When they discover the amusement park and ferris wheel they're blown away by the juxtaposition of the wasteland that surrounds them and the associations ('nostalgia' as it were) that such a carnival ride carries for many of us. It simultaneously *doesn't belong* and is yet all at once *perfectly situated in the environment*.

It is to say 'surreal', which is adjacent to the idea of *being real*, in terms of our "perception of what is and isn't plausible, if not possible."

This is at the heart of suspension of disbelief, because in essence, virtual worlds are a lie, like fiction, and good fiction violates expectations in order to tell us truths about reality. As part of our ability to differentiate bullshit from reality, there is to say an element in our bullshit detectors (doubtless evolved over many 10's of thousands of years), that is designed to not merely detect what is absurd in our limited experience, but to incorporate absurdity into everyday experience. In that sense part of our rationality is the acceptance of irrational experiences, learning from it, and discovering 'a proper place for each thing' in the "models of the world" we all carry around in our heads. Eventually we normalize the absurd, it becomes the new reality, and what remains unassimilated becomes superstition (real or otherwise), a figment, or an anomaly.

One of the best examples I've encountered is The Last of Us: Left Behind, a good chunk of which is spent in a mall. And they nailed the environment perfectly I would say.

Or for those who don't own a PS4, a more accessible example is a map in NMRIH aptly called "the museum", and few words better do it justice than to go play it yourself--that is, if you really want to know what I mean by a 'situated environment'.

What better way, during this pandemic, to get out of the news cycle and into your own head? Sometimes the best way to escape isn't outside, it's within.

There are a few constants in Software Development:

1) The requirements always change.
2) Don't trust input.

Silly me was so naive to ignore 1 and 2 and later I dealt with the consequences.

1) Oh, we have this new API and we're only going to build Google Maps interfaces with it. Nice, easy task. We won't have to address the other parts of the library, wooh! The next day: "Yeah guys, we kinda wanna use the other parts now". Me: sigh.

2) Simple task: I have my API accept CSV files so I can generate graphs out of them. What could go wrong? Provide wrong file? I caught that. Provide completely fucked up and garbled CSV? Whoops.

I went to an interview a few days ago, just out of curiousity, even though i was sure that i won't be getting any "android developer jobs" there . it was a mega job fair. in one company, me and my friend neil(fake name) went. the interviewer guy was willing to give neil a package upto 10LPA (its a great offer for freshers in my country) based on his current skills of php js, react,angular, ... web stuff .
I had this assumption( and neil did too , we both kind off had the same mindset) that a company teaches us things, we just have to be a little famous/accomplished. So i thought why not? i am accomplished. i got 2 apps on playstore, i am an AAD certified Android dev and know a lot of android stuff, i am quite famous. i am equally as deserving as neil.

But what happenned was something different. When my turn came, the interviewer said " If you have no knowledge of phy/js/node/angular, why are you sitting here?" to which i said " i presumed company would teach me, since i bring some level of expertise from other fields"

so he told me some hard truths **"Companies are fast paced. they don't have time to train you in everything. we seek for candidates having some level of knowledge in the domain, so that we could brush up your skills, increase your knowledge to current requirement and push you to production engineer asap, so that you could be worthy of your salary"**

This is completely correct. i have stuck myself in such a career that its very difficult to sell myself for other job profiles. And from what i have seen, companies seek a very high level of proficiency in this field and rarely recruit freshers( or even if they do, salaries will be aweful)

. Now i am so unsure about what to do next:

A.) keep learning more and more of android and look for job in it. And even if am getting an aweful job offer, just sulk and take it
B.) do open source work/gsoc work?( its a good way to earn more recognition/stipend/knowledge and sometimes even job offers)
C.) learn web dev, data sciences, blockchain, cloud or other stuff that i don't yet know
D.) go back to ds algo / competitive? (because having good competitive knowledge is a safe zone. you are assumed as apure fresher with 0 level of practical knowledge but good level of mathemetics)

I know i am going suck in all of the above except maybe (A) or (B) because (C) is something that am unsure would grab my interest (and even if it did, i am sure i need another 1-2 years to be somewhat good at it) and (D) is something i myself know am uncapable of , i am an average shit in maths(but might mug it all up if i pull all nighters for 1 year)

Rubber ducking your ass in a way, I figure things out as I rant and have to explain my reasoning or lack thereof every other sentence.

So lettuce harvest some more: I did not finish the linker as I initially planned, because I found a dumber way to solve the problem. I'm storing programs as bytecode chunks broken up into segment trees, and this is how we get namespaces, as each segment and value is labeled -- you can very well think of it as a file structure.

Each file proper, that is, every path you pass to the compiler, has it's own segment tree that results from breaking down the code within. We call this a clan, because it's a family of data, structures and procedures. It's a bit stupid not to call it "class", but that would imply each file can have only one class, which is generally good style but still technically not the case, hence the deliberate use of another word.

Anyway, because every clan is already represented as a tree, we can easily have two or more coexist by just parenting them as-is to a common root, enabling the fetching of symbols from one clan to another. We then perform a cannonical walk of the unified tree, push instructions to an assembly queue, and flatten the segmented memory into a single pool onto which we write the assembler's output.

I didn't think this would work, but it does. So how?

The assembly queue uses a highly sophisticated crackhead abstraction of the CVYC clan, or said plainly, clairvoyant code of the "fucked if I thought this would be simple" family. Fundamentally, every element in the queue is -- recursively -- either a fixed value or a function pointer plus arguments. So every instruction takes the form (ins (arg[0],arg[N])) where the instruction and the arguments may themselves be either fixed or indirect fetches that must be solved but in the ~ F U T U R E ~

Thusly, the assembler must be made aware of the fact that it's wearing sunglasses indoors and high on cocaine, so that these pointers -- and the accompanying arguments -- can be solved. However, your hemorroids are great, and sitting may be painful for long, hard times to come, because to even try and do this kind of John Connor solving pinky promises that loop on themselves is slowly reducing my sanity.

But minor time travel paradoxes aside, this allows for all existing symbols to be fetched at the time of assembly no matter where exactly in memory they reside; even if the namespace is mutated, and so the symbol duplicated, we can still modify the original symbol at the time of duplication to re-route fetchers to it's new location. And so the madness begins.

Effectively, our code can see the future, and it is not pleased with your test results. But enough about you being a disappointment to an equally misconstructed institution -- we are vermin of science, now stand still while I smack you with this Bible.

But seriously now, what I'm trying to say is that linking is not required as a separate step as a result of all this unintelligible fuckery; all the information required to access a file is the segment tree itself, so linking is appending trees to a new root, and a tree written to disk is essentially a linkable object file.

Mission accomplished... ? Perhaps.

This very much closes the chapter on *virtual* programs, that is, anything running on the VM. We're still lacking translation to native code, and that's an entirely different topic. Luckily, the language is pretty fucking close to assembler, so the translation may actually not be all that complicated.

But that is a story for another day, kids.
And now, a word from our sponsor:

<ad> Whoa, hold on there, crystal ball. It's clear to any tzaddiq that only prophets can prophecise, but if you are but a lowly goblinoid emperor of rectal pleasure, the simple truths can become very hard to grasp. How can one manage non-intertwining affairs in their professional and private lives while ALSO compulsively juggling nuts?

Enter: Testament, the gapp that will take your gonad-swallowing virtue to the next level. Ever felt like sucking on a hairy ballsack during office hours? We got you covered. With our state of the art cognitive implants, tracking devices and macumbeiras, you will be able to RIP your way into ultimate scrotolingual pleasure in no time!

Utilizing a highly elaborated process that combines illegal substances with the most forbidden schools of blood magic, we are able to [EXTREMELY CENSORED HERETICAL CONTENT] inside of your MATER with pinpoint accuracy! You shall be reformed in a parallel plane of existence, void of all that was your very being, just to suck on nads!

Just insert the ritual blade into your own testicles and let the spectral dance begin. Try Testament TODAY and use my promo code FIRSTBORNSFIRSTNUT for 20% OFF in your purchase of eternal damnation. Big ups to Testament for sponsoring DEEZ rant.

UWP suck, I don't wanna hurt yall feeling but it's time to face the truths:
+ SandBox
+ Less Job Offer
+ Development more Complicated than Web App
+ Microsoft not create perfect hardware to make sure our app get to more consumers (the Pro X is failure)
+ Poor Optimized
Poor Optimized ?
the Windows 10 optimization is joke, all my surface laptop, pro, book I have tested. They claim that consume less Ram, but when using it along side electron and Win32 app. It feel so much choppy and lag. I mean WTF ?
UWP was made for optimize low specs SoC such as ARM base, now my laptop running on a core I5 + GPU still lag ??
I'm sorry but this is just sad. Im moving back to win32. WinRT sooner or later will end supported
And Microsoft will improve the Win32 Api