If all you have is a hammer, everything looks like a nail!

This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.

Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.

While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.

Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.

I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.

Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!

Boss asks me to prefer deadlines over good engineering practice. Says meeting a deadline is always more important than building things the right way.

Son, when the company goes out of business due to hundreds of millions of dollars in losses due to shoddy engineering, do you want to be the one to go to the spouses of everyone who lost their job and say "your spouse lost his job because we didn't take a few more days to build the product right"?

Son, when the company's product blows up in a child's face like a Note 7 because of your shoddy engineering, do you want to go to the funeral and tell the parents "your child died because we didn't take a few more days to build the product right"?

Fuck your arbitrary deadlines. I prefer not allowing for so much grief and suffering to be on my soul.

NEVER USE GOTO!

One of our senior dev enjoys berating the other devs because they don't check-in code according to his schedule (once a day, once an hour..he flip-flops a lot), then when they do, he 'reviews' their code, beating them up because of incomplete features, commented out code..petty..petty nonsense.
Ex. (this occurred couple of weeks ago).

Ralph: "The button click code in this event isn't complete"
Dev: "No, its not, the code in my development branch. You said it was best practice to check in code daily whether the code worked or not. I didn't finish the event last night and ..."
Ralph: "Exactly. Before you check any code into source control, it has to work and be 100% complete. What if someone moved that code into production? What happens if that code got deployed? I'm not even going talk about the lack of unit tests."
Dev: "Uh..well..the code is on the development channel, and I branched the project in my folder ...I didn't think it mattered.."
Ralph: "Ha ha...you see what happens when you don't think...listen..."
- blah blah blah for 10 minutes of hyperbole nonsense of source control check-in 'best practice'

This morning Ralph's computer's hard-drive crashed.
Ralph: "F-k! ..F-k! ... my f-king computer hard drive crashed!"
Me: "Ouch...did you loose anything important?"
Ralph: "A f-king week of code changes."
Me: "You checked everything into source control on Friday ...didn't you?"
Ralph: "F-k no!...I got busy...and...f-k!"
Me: "Look at the bright side, you'll have a good story to tell about the importance of daily check-ins"

Oh...if looks could kill. Karma...you're the best.

"Graphics don't matter."

I ranted a while back about gamedev being hard to get into for me, and, today, user @DOSnotCompute posted a similar experience.

I had a couple more thoughts, so thought should post them here (FUCK! It ended up being too fucking long! sorry!)

So I was watching the making of mortal kombat 3 on yt, which was pretty amazing btw because I got to see the actors of the sprites in game which were engraved in my and thousands of others kids minds.

Anyhow, the creators of the series, John Tobias and Ed Boon, were interviewed and what not. And it hit me that while both were the designers, John was the main artist and Ed was the programmer (at least for MK1). Another game that comes to mind Super Meat Boy, and I bet hundreds of others did the same.

And it got me thinking, maybe that's my problem, I just need an artist.

And I think the reason why I never thought of that is because of this idea that graphics don't matter.

"you don't need an artist. You don't need graphics. The most important thing is the gameplay."

What a load of shit.
A lot of people believe that because they got tired of polished AAA games with automatic and predictible gameplay.

People started parrotting this knee jerk of a conclusion since then.

It's dumb. Imagine if Infiminer, one of the games Minecraft was based on, which btw looks terrible, had all the same features Minecraft had.
I would still not touch that shit with a pole.

Graphics ARE important. Games are on the VISUAL medium.
That doesn't mean you're sucking Sony's dick on every AAA release or that every game should be made with UnreUnityCocksReloadedEngine.

Some level of visual craft is required for a game ro be considered such.

(btw, I think most of you guys here get this, not trying to pander, just that I want to make it clear that I'm not accusing this community of being guilty of this)

If a game looks bad (given, bad can be subjective), if it gives the impression that it wasn't seriously made, then you kinda lower your expectations.

People get hyped on games that look good, because it means that the game could be good. Games that look unoriginal or terrible won't get played, wether they're good or not. And I think it's a reasonable reaction.

How many times did I hear things like "Look at x video game from the 90s, the graphics are terrible but it's fun as hell".

That is an absurd statement. The level of production some NES games went through is insane. We're talking millions of dollars for games that today might look primitive.

The graphics weren't shit back then, and even today you could say that they are simpler but also of excellent craftsmanship.

I'm not into creating art, I hate it in fact because you can't quantify the success of produced art.

So, duh, find an artist. Ok, how? This is the part where I have no fucking idea how.

You start spamming shit like "I need an artist" online? I dunno, something for another post I guess.

I guess the most healthy thing I could do is making demos that might look like shit just to get experience so that when I get to find an artist, I have practice already.

Fml... you keep getting the weekly discussions right on point.

I started with the last guys right out of university... just out of Hospital.

With a brand new degree and a Crohn’s diagnosis I stepped into the first place I found hiring. They were good guys, after a junior dev... to get stuck in their muck.

I did! I nailed project after project, tricky development after tricky development. I spent 5 years with them and over those years things changed.

They had a mass cull... the original idea was to get rid of the useless middle managers, the ones managing other managers being managed by another manager for no real reason.... the ones that do fuck all with their day.

But the fucking idiots upstairs put the job of working out the cull in the shitty middle managers hands.

So, instead, they cut the titles senior, junior and everything in between. Everyone was just a thing, no senior things, no junior things. Just things.

Once they’d done that they said “we’ll we have this many things, they’re all the same, let’s get rid of the things with the highest pay checks because the other things can do it just as well for less money”...

And that’s how they cut 50% of their senior techs.

I was one of the ones left behind but the damage became obvious quick. The middle managers barked out orders at people who couldn’t complete them, and everything went to shit.

My team was rebranded twice in as many years... an obvious ploy for funding, but the cost of the team fluctuated like hell because contractors had to fill the senior positions at 3 times the cost.

Then the managers started barking out Self contradictory orders. Do this, but this way...

This would work, but not that way... try explaining that to a group of non-technical, useless as fuck middle managers. It took months, and shit flows downstream so we got the bulk of the hassle for it.

Then my boy Morpheus, got a warning... they threatened his contract for saying “this will work, but not that way”.

He kept the contract, and the manager giving him the warning said he didn’t think he should... but he, and all the middle fuckwits don’t have the balls to stand up against nonsense.

That was the breaking point for me, I handed in my notice and told them a month was what they could have.

I didn’t have a position or an idea of where to go, a few long-standing offers as back up in a pinch but not the perfect job.

On the Thursday I decided I was done, I let my manager know. Then I boshed the fuck out of my CV and updated my profiles.

My phone started ringing off the hook, a senior NG2/MEAN/Ionic dev on the market is like candy to recruiters. They’re lovely too.

I went to a few interviews that were okay but not great. Then a company got in touch... one that I immediately recognised as an IT book publisher. They said they were looking for NG/NG2 devs, senior. winner! Set up the interview.

So I’d spent the weekend with the missus, about an hour away from mine and 2 from the interview. I hadn’t planned on staying there but at 6ish she looked over at me and said “do you have to go” <- imagine that with puppy dog eyes from a gorgeous Slovenian lass.

I folded quicker than a shitty pancake toss.

We spent the night together but that meant I had to be up at 6, to go back to mine, iron my interview clothes and make it to the train to manage the interview. Fuck. I did it, but I was at the interview wired on caffeine and struggling to be awake and coherent. I still managed, that’s what I do, I make do and try to do well regardless of the situation.

That comes from being ill btw, when you’re dealt a shitty hand you learn to play it well.

They were good guys, the heads all knew what they were on about, not the middle management bs I was used to.

They demoed me live with an ng1 test, which was awesome as hell to play with.

We chatted, friendly and cool guys! I loved the place.

The end of the week they got me in for second round. Ng2 and competence test, again I went for it!

Positive feedback and a “we’ll get back to you ASAP, should be by Tuesday”...

Tuesday was the Tuesday before the Friday I was due to leave the old company... I was cutting it close.

On the Monday the offers started rolling in, a few C# ASP MVC positions, cool but I was holding out for the guys I’d interviewed with.

Then Tuesday comes around, I’m nervous as fuck but it’s okay because I knew regardless I can pay the rent in December with one of the offers.

Then said yes!

The thing that seemed most important in the process was my ability to talk to any fucker. If you’re coming up to interview, talk to everyone, the grocer, your barista, the binmen, anyone. Practice that skill above all others.

I start tomorrow morning! I can’t wait.

Final thought: middle managers are taints.

How I got selected for GSoC'19:
I will describe my journey from detail i.e from the 1st year of the college. I joined my college back in 2017 (July), I was not even aware of Computer Science. What are the different languages of CS, but I had a strong intuition of doing BTech from CSE only?

So yeah I was totally unaware of the computer science stuff, but I had a strong desire to learn it and I literally don’t know why I had this desire. After getting into college, I was learning HTML, Python, and C, also I am really thankful to my friends who really helped me to learn, building logic and making stuff out of it. During the 1st month of joining the college, I got to know what is Open Source, GSoC, Github due to my helpful seniors. But I was not into Open Source during my 1st year of college as I thought it is very difficult to start. In my 1st year, I used to do competitive programming and writing scripts in Python to automate various stuff. I never thought that I would even start doing Open Source development, also in the summer vacations after the 1st year I used to practice programming on HackerRank and learnt an awesome course called Automate the Boring Stuff with Python(which I think is one of the most popular courses for Python) which really helped me to build by Python skills.

Now the 2nd year came, I was totally confused between doing Open Source development or continue with my Competitive programming. But I wanted to know about Open Source development, so I thought to start now will be a good idea. I started attending meetups of OSDC(Open Source Developers Club) which is a hub of my college, which really helped me to know more about Open Source development from my seniors. I started looking for beginner friendly projects in Python on the website Up For Grabs, it’s really helpful for the beginners. So I contributed in a few of them, and in starting it was really tough for me but yeah I continued, which really helped me to at least dive into Open Source. Now I thought to start contributing in any bigger project, which has millions of lines of code which will be really interesting. So I started looking for the project, as I was into web development those days so I thought to find a project which matches my domain. So yeah I finally landed on Oppia:
Oppia

I started contributing into Oppia in November, so yeah in starting it was really difficult for me to solve any issue (as I wasn’t aware of the codebase which was really big), but yeah mentors at Oppia are really helpful, they guided me which really helped me to start my journey with Oppia. By starting of January I was able to resolve around 3–4 issues, which helped me to become the collaborator at Oppia, afterward I really liked contributing to it and I was able to resolve around 9–10 issues by the end of February, which landed me to become a Team Member at Oppia which was really a confidence boost and indication for me that I am in the right direction.

Also in February, the GSoC organizations list was out, and yeah Oppia was also participating in it. The project ideas of Oppia were really interesting, I became even confused to pick anyone because there were 4–5 ideas which seemed interesting to me. After 1–2 days of thought process I decided to go for one of them, i.e “Asking students why they picked a particular answer”, a full stack project.

I started making proposals on it, from the first week of March. I used to get my proposal reviewed frequently from the mentors, which really helped me to build a good and strong proposal.

I must say a well-defined proposal is the most important key for getting selected in GSoC, also you must have done some contributions to the organization earlier which I think really maximize your chances of selection in GSoC.

So after my proposal was made, I submitted it on the GSoC website.
Result Day:

It was the result day, by the way, I had the confidence of being selected, but yeah I was a little bit nervous. All my friends were asking when is your result coming, I told them it will come at 12.30AM (IST). Finally, the time came when I refreshed the GSoC website, Voila the results were out. I opened the Oppia organization page, and yeah my name was there. That was the day I was really happy and satisfied, I was thinking like I have achieved something in my life. It was a moment of pleasure for me, I called my parents and told them my result, they were really happy for me.

I say cracking GSoC is worth it, the preparation you do, the contributions you do, the making of the proposal is really worth.

I got so many messages from my juniors, friends, and seniors, they congratulated me. After that when I uploaded my result of Facebook and LinkedIn, there were tons of comments and likes on the post. So yeah that’s my journey.

By the way, I am writing this post after really late, sorry for it. I must have done it earlier, but due to milestone 1 of GSoC, I was busy.

Combatting imposter syndrome is all about being more realistic with yourself imo.

Not in the way you might think. By realistic, I mean you NEED to regularly tell yourself that you are doing your best - especially in the work or areas that can promote insecurities of “not being good enough”. Acknowledge that you are only human, that all of us are different, that all of us make mistakes, and all of us have different interests in life. That, and practice gratitude for your situation. Your interests and decisions lead your different paths, so might as well embrace, enjoy, and love your uniqueness.

That being said, I also think it’s important to do difficult things. I think @wisecrack said it the best in that “real learning feels like falling”. Like the uncertainty of the abyss causes the most anxiety. Next time you feel like you don’t belong, recognize and separate that feeling and reframe it as a symptom to your own self improvement process. Take that risk and do things that are uncomfortable in the pursuit of personal success.

Wrote this on another thread but wanted to do a full post on it.

What is a game?

I like to distinguish between 1. entertainment, 2. games, 3. fun.

both ideally are 'fun' (conveying a sense of immersion, flow, or pleasure).

a game is distinct (usually) from entertainment by the presence of interaction, but certain minimalists games have so little decision making, practice, or interaction-learning that in practice they're closer to entertainment.

theres also the issue of "interesting" interaction vs uninteresting ones. While in broad terms, it really comes down to the individual, in aggregate we can (usefully) say some things, by the utility, are either games or not. For example if having interaction were sufficient to make something a game, then light switches could become a game.

now supposed you added multiple switches and you had to hit a sequence to open a door. Now thats a sort of "game". So we see games are toys with goals.

Now what is a toy?

There are two varieties of toy: impromptu toys and intentional toys.

An impromptu toy is anything NOT intended primarily, by design, to induce pleasure or entertainment when interacted with. We'll call these "devices" or "toys" with a lowercase t.

"Toys", made with the intent of entertainment (primarily or secondarily) we'll label with an uppercase T.

Now whether something is used with the intent behind its own design (witness people using dildos, sex toys, as slapstick and gag items lol), or whether the designer achieves their intent with the toy or item is another matter entirely.

But what about more atmospheric games? What about idle games? Or clickers?

Take clickers. In the degenerate case of a single button and a number that increases, whats the difference between a clicker and a calculator? One is a device (calculator) turned into an impromptu toy and then a game by the user's intent and goal (larger number). The second, is a game proper, by the designers intent. In the degenerate case of a badly designed game it devolves into a really shitty calculator.

Likewise in the case of atmospheric games, in the degenerate case, they become mere cinematic entertainment with a glorified pause/play button.

Now while we could get into the definition of *play*, I'll only briefly get into it because there are a number of broad definitions. "Play" is loosely: freely structured (or structured) interaction with some sort of pleasure as either the primary or secondary object, with or without a goal, thats it. And by this definition you can play with a toy, you can play a game, you can play with a lightswitch, hell you can play with yourself.

This of course leaves out goals, the idea of "interesting decisions" or decision making, and a variety of other important elements.

But what makes a good game?

A lot of elements go into making a good game, and it's not a stretch to say that a good game is a totality of factors. At the core of all "good" games is a focus on mechanics, aesthetics, story, and technology. So we can already see that what makes a good game is less of an either-or-categorization and more like a rating or scale across categories of design elements.
Broadly, while aesthetics and atmosphere might be more important in games like Journey (2012) by Thatonegamecompany, for players of games like Rimworld the mechanics and interactions are going to be more important.

In fact going a little deeper, mechanics are usually (but not always) equivalent to interactions. And we see this dichtonomy arise when looking at games like Journey vs say, Dwarf Fortress. But, as an aside, is it possible to have atmospheric games that are also highly interactive or have a strong focus on mechanics? This is often what "realistic" (as opposed to *immersive*) games try to accomplish in design. Done poorly they instead lead to player frusteration, which depending on player type may or may not be pleasureable (witness 'hardcore' games whos difficulty and focus on do-overs is the fun the game is designed for, like roguelikes, and we'll get to that in a moment), but without the proper player base, leads to breaking player flow and immersion. One example of a badly designed game in the roguelike genre would be Early Access Stoneshard, where difficulty was more related to luck and chance than player skill or planning. A large part of this was because of a poorly designed stealth system, where picking off a single enemy alerted *all enemies* nearbye, who would then *stay* alerted until you changed maps, negating tactics that roguelike players enjoy and are used to resorting to. This is an important case worth examining because it shows how minor designer choices in mechanical design can radically alter the final quality of the game. Some games instead chose the cheaper route of managing player *perceptions* with a pregame note: Darkest Dungeons and Amnesia TDD are just two I can think of.

Some of you know I'm an amateur programmer (ok, you all do). But recently I decided I'm gonna go for a career in it.

I thought projects to demo what I know were important, but everything I've seen so far says otherwise. Seems like the most important thing to hiring managers is knowing how to solve small, arbitrary problems. Specifics can be learned and a lot of 'requirements' are actually optional to scare off wannabes and tryhards looking for a sweet paycheck.

So I've gone back, dusted off all the areas where I'm rusty (curse you regex!), and am relearning, properly. Flash cards and all. Getting the essentials committed to memory, instead of fumbling through, and having to look at docs every five minutes to remember how to do something because I switch languages, frameworks, and tooling so often. Really committing toward one set of technologies and drilling the fundamentals.

Would you say this is the correct approach to gaining a position in 2020, for a junior dev?
I know for a long time, 'entry level' positions didn't really exist, but from what I'm hearing around the net, thats changing.

Heres what I'm learning (or relearning since I've used em only occasionally):

* Git (small personal projects, only used it a few times)
* SQL
* Backend (Flask, Django)
* Frontend (React)
* Testing with Cypress or Jest

Any of you have further recommendations?

Gulp? Grunt? Are these considered 'matter of course' (simply expected), or learn-as-you for a beginner like myself?

Is knowing the agile 'manifesto' (whatever that means) by heart really considered a big deal?

What about the basics of BDD and XP?

Is knowing how to properly write user-stories worth a damn or considered a waste of time to managers?

Am I going to be tested on obscure minutiae like little-used yarn/npm commands?

Would it be considered a bonus to have all the various HTTP codes memorized? I mean thats probably a great idea, but is that an absolute requirement for newbies, or something you learn as you practice?

During interviews, is there an emphasis on speed or correctness? I'm nitpicky, like to write cleanly commented code, and prefer to have documentation open at all times.
Am I going to, eh, 'lose points' for relying on documentation during an interview?

I'm an average programmer on my good days, and the only thing I really have going for me is a *weird* combination of ADD and autism-like focus that basically neutralize each other. The only other skill I have is talking at people's own level to gauge what they need and understand. Unfortunately, and contrary to the grifter persona I present for lulz, I hate selling, let alone grifting.
Otherwise I would have enjoyed telemarketing way more and wouldn't even be asking this question. But thankfully I escaped that hell and am now here, asking for your timeless nuggets of bitter wisdom.

What are truly *entry level* web developers *expected* to know, *right out the gate*, obviously besides the language they're using?

Also, what is the language they use to program websites? It's like java right? I need to know. I'm in an interview RIGHT now and they left me alone with a PC for 30 minutes. I've been surfing pornhub for the last 25 minutes. I figure the answer should take about 5 minutes, could you help me out and copypasta it?

Okay, okay, I'm kidding, I couldn't help myself. The rest of the questions are serious and I'd love to know what your opinions are on what is important for web developers in 2020, especially entry level developers.

Great practice/skill sharpening idea for my fellow mad dogs that like to get down in multiple languages/syntaxes:

Pick something simple that won't cause too much stress, but will make you sweat a little bit and put up a good fight, ha!!!

For example, I picked the classic "Caesars Cipher" and picked 5 languages to create it in! I picked Dart, Java, Python, CPP, and C. Each version does the same thing:
1. Asks for a message
2. Runs the logic
3. Prints the message cipher.
4. To decrypt, you just run the same program again and enter the cipher text at the message input prompt. The message gets deciphered using the same logic an shows up as the original text.

The kicker:
Only dox/books allowed for reference. Otherwise it wouldn't push you to get better!!!

Python, C, and CPP were EASY, even with me never having used C before. I am great at using Dart, and that one really challenged me for some reason, but I finally got it. The previous 3 langs took less than 40 lines of code each (with Python being only 18 I believe). Dart actually took somewhere around 50, and Java took about 371784784. (Much love to Java though for real!)

Kinda boring as shit, but I gotta tell you it felt fuckin GREAT to look at all 5 of those programs after completing them, no matter how barbaric... especially when you complete 1 or 2 in a language you've never used or maybe felt really challenged by. Simple exercises that hold a lot of important, relatable logic no matter the subject is our lifeblood!!!