"We promised this to a client by the end of the week." Every sales team ever

I have watched this video year ago, and recently I have received a use case for an interview from a company that indirectly asking about tech debt. Thank you very much Dave!

Tech Debt in my 30 odd years experience is when an employer makes demands for output and then refuses to supply neither the budget, personnel or the hardware resources to meet those demands. Unrealistic expectations, inability to delegate and unreasonable attitudes on the part of management are all part of being set up to fail. If you can't manage that you have no business in the business. If an employer is unwilling or unable to supply the resources to pay for training, hardware upgrades overtime etc. Snowflake servers? LOL my solution to those has always been to let the magic smoke escape or just outright kill them. Invariably the person or group that implemented them and no one took responsibility for them. When marketing makes promises that engineering can't possibly fulfill. That's on them. In EVERY senior tech , engineering, or infrastructure position I've ever interviewed for I ALWAYS asked the question. Can I delegate? Can I hire or fire? What's the budget? How many "bosses" will I have? Whatever the end result might be if I have no power to make positive change or meet management's unrealistic expectations? That has to be discussed up front.

Outrageous value in this video! Just wow! In addition to the actual technical knowledge, the bureaucracy part is GOLD!

@tutoriaLinux

4 жыл бұрын

It's not glamorous, but it's the reality of this business :-D. Cheers!

First video that i have seen that somebody actually codify this matter.... Great video! Thanks.

The rest of this course has been great, but topics like this are super welcome in this playlist, and if I'm being honest, I'm upset it took getting this far to have a conversation about it. I think learning the nuts and bolts of the linux ecosystem is important, but knowing what some of the day-to-day experiences that a Sysadmin is likely to experience is just as helpful. It lets you apply the stuff you've been tweaking in this course in a more smart way. I'd love getting one of these videos as a "coffee break" among the other lessons in the course. Maybe you've updated things and it's more like that now. But these sidebars are super valuable and this resonated with me until I almost fell out of my chair.

"We promised this to a client by the end of the week." I had that one recently. Job was: 1. Set up a new office - this includes all the computers, monitors, switches etc with 22 computers total. 2. Set up VPN and a dialer, with copies of the sound files transfered over to a specific server. 3. Make sure the internet connection can support the 22 computers and users. Now. As soon as I started making phone calls, I realised that 2 weeks was unreasonable, and the new employees were due at the start of next week. 3 weeks before the fiber would even be lit. Ugh. So set up 4G modem, Watchguard BOVPN to Finland from where all the task scheduling would be happening. Takes 4 hours by train to get to the new office for me, so I can't move freely. Once I leave, I'm not coming back unless it's an emergency. The NAS unit meant for storage of soundfiles didn't make it with me. No one else knows how to work one. Nevermind, just send everything over VPN immediately to Finland, I don't care any more. Spend literally 48 hours updating and installing Microsoft software on these 22 stations because we didn't image them before sending them out. Goddamn. And no over time. :( If feel your video. It speaks to me.

@tutoriaLinux

7 жыл бұрын

Oooohhh man...that's rough. No overtime!? :-o. Time to start looking for a new gig...but nicely done, and sounds like you planned it out well with the ridiculous restrictions that you had.

@alrod9535

5 жыл бұрын

Underpromise and over deliver comes to mind here. Always give a time window that seems long but not too outlandish. If you finish sooner, you've exceeded expectations because you knew it would take about a month, but you asked for 2 months to complete.

Iam currently listening to the phoenix project and the whole concept of that book is about this. I havent realized that till now, so thank you for your video. Keep it up, love your content.

Aha, it may be a boring subject for you to have to talk about, but I found your slides and the way you talked about it entertaining lol, so I paid attention the whole vid. I'm glad I found your channel, I got my RHCSA back in September but I haven't been practicing since then, and I have an interview tomorrow for Linux tech support at a really awesome company so I was looking for something to listen to just to brush up and make sure I'm refreshed for the interview questions. This video is really good because I've never actually worked in IT, so I'm not yet familiar with things like this that will come with the job. And I'm glad you made me aware of it, so I can at least have a little bit of mental preparation for when I inevitably run into it!

This was a very helpful video. Not something I often think about, but great to make it a priority when working on projects. Please keep more general topic videos like this coming.

Thank you, I didn't knew that problem had a name.

I've shared this with my team as possibly the most succinct explanation of Tech Debt and, in particular, how it even has its uses. Working with Agile developer folk focussed on Delivery (deliberate capital D) there is a predisposition towards creating and accruing TD, particularly in the NFRs. Despite cool collaboration the business drives the behaviours and outcomes. It is a constant battle. Having information like this that is easily digestible to all levels of staff is invaluable. Very nice. Well done indeed.

Now I understood how much tech debt I am owing my project team. Thanks Dave 👍

As a former employee of Comcast, I know this first hand. Sure I was only Tech Support in a call center, but we had like 10+ systems we had to use for various purposes in an ENTRY level position. Many of those systems were outdated and did the same things other systems did; while I understand the importance of redundancy, it was ridiculous and I'm sure it had something to do with why our computers and programs ran so slow. That's just on the software/database side, I won't even go into detail as to the tech debt that was on the phone support side LOL

Excellent video. Applicable to all us Tech guys in the industry. Highly appreciate you content. Keep posting. 👍

Like you said, it's not always bad decision:D I like to extend this to: "decisions made on best knowledge at the moment decision was made" Thanks for videos, even that I'm a software developer not an admin or DevOp, I love this series. It really!! improved my workflow on Linux machines with terminal only :)

This video was SO good.....thank you!

Excellent subject choice to spend a few minutes on. Well Done.

Great video. I wish to learn more from you.

so much wisdom man thank you

Of all your (great) videos this is the first that moved me to comment. With a wry smile all I can say is "tech debt" (new word to me) in my opinion is a sad fact of life and as one commenter already joked is why a lot of us have or at least often retain our jobs! (whether intentional or not!) What I will say is there are those of us who accrue this debt out of some sick sense of self-verification (e.g. the dev who deliberately writes shabby or cryptically commented code so that people might need him years after the product has launched or e.g. 2 the sysadmin who builds a server with so many moving parts only he understands how to tweak) are only actually making things worse for themselves down the road. Because he will move on or have to train someone (eventually) and when he does he will actually not want to be "that builder" who no longer picks up his phone when panicked old customers come calling or who is woefully embarrassed when another tech says to him "so... how come you built it like that?". Personally I think this is more a personality disorder or a sign of immaturity which is exacerbated by tech's wanting to please and business teams taking advantage for commercial or convenience purposes. As managers we must all just stop and be responsible. Yet it's a balance isn't it, since if we are too cautious and try to tick every box we would never launch anything. Maybe that's about the time to retire. Good people, with good consciences and solid work ethics is all we should ever need. In practice this comes down to the courage to recruit them and moreover to pull up the others on this stuff. The only way we can do this is to be sufficiently technical (and interested!!) ourselves to realise when they are straying. Good managers are rare. Sorry. My 2 pennies worth. Hey by the way... what's the best way to 'support' you these days? Patreon or just a donation? and btw2... where are those "networking vids you were promising!? Am I really supposed to go to your competitors for these? jeez..."

@tutoriaLinux

7 жыл бұрын

Love this comment -- I can tell that you've felt this pain before :-D. Support? Patreon works well, but honestly just watching my videos and commenting/sharing is probably the best way to help out. Thanks! And yeah, the networking course is still on my 'to do' list. I think it will be the next big piece of work I do after finishing the Python course and the Red Hat Certified Engineer course. Sorry for the wait!!

Yay! First video from Dave in a month! Thanks for introducing the concept! You haven't been posting much vids recently. Congrats on your new gig and your "repatriation" lol! I hope you're digging it(damn, that's too many exclamation marks for two paragraphs haha)! Dave, I've finally taken the plunge and bought your course on Udemy about two weeks ago. It's f-in' killer. You rock, playboy! I had a question about LXC: being a "special snowflake"(having a habit of doing everything backwards, etc.) that I am, I was curious if I should attempt to deploy LXC containers with LEMP stacks on a VPS(in a "production" environment, if you will)? Basically, Word Press servers that I crank out on my home machine, containerize them and deploy on a VPS. I wanted to do it to get a handle on this technology(and for shits and giggles, of course), but now I'm thinking that bare LXC wasn't really designed for this plus it could be a little over my head, skill-wise at this point. Should I just abandon this pursuit and set up, say, 1 nginx per a VPS with multiple websites(just like you demonstrate in your course) or should dive into some other, more appropriate, "production-level" containerization technology(like Docker or whatever the cool kids use these days) once my skills in setting up the former variant solidify a little? I've spent WAY too much time free time googling this particular question than I'm willing to admit to(haven't had such cramps in my traps in years lol), so I just decided to ask flat out hehe. 20k subs?! Congrats on that, too! The last time I checked I think you were at 18. The horde's a'growin' lol. And again-you ROCK! \w/

@cMaXeJIJIo

7 жыл бұрын

Hey, is this question discussed in your book on containers? Maybe I should just buy that lol. No, seriously: this technology interests me and I'd like a more in-depth document on it written by a tech person who can actually explain things in plain English xD

You made almost a 15 minute video to tell me that some people are not worth working with and need to learn things the hard way.

I think we all tech guys have faced it. The manager comes and says I want it in two weeks.

The reason i have a job.

Im gonna watch this later

Hey tutorialLinux, Windows Admin and Security Analyst here. Looking to start migrating some unix'able things over from Windows to, probably, Ubuntu server. I started this endeavor this week and am looking to get started. My job is fine with sending me to seminars and boot camps so I was wonder if you knew of any linux bootcamps to where I can get some familiarity being a unix admin. Thanks. Edit: Also your explanation on tech debt reminded me of the explanation of the different types of "work" in "The Phoenix Project." As a matter of fact your entire video kinda reminded me of that (of what I've watched so far.)

@tutoriaLinux

7 жыл бұрын

Hey, that's an interesting question (and an enviable position to be in!). I'm not really familiar with Unix/Linux bootcamps, but it's quite possible that they exist. I'd recommend having a look around the USENIX site and seeing if you can find any bootcamp companies/recommendations around there. They are an industry organization that I really trust. For the basics, doing an LPIC (Linux Professional Institute) or Linux+ (CompTIA) certification boot camp is probably a good way to spend your cash.

How did you work in all this jobs ? I am a sysadmin guy and I want to have knowledge about software developpment, data science & ML for a project that I envasion, so what should be my next job, if you can help me to answer this question please ?

"We promised our customer that by the end of the week we will paint all his walls in this incredible light blue colour, using this old red paint cans. You can do that, don't you?"

Facing that right now- and really I am the one to blame while trying to tell that this thing is REAL =_= ! Beware!

This is very useful.

Have definitely been forced to deploy prototypes to production before... some executives just don't listen! "Good luck", I say.

@tutoriaLinux

7 жыл бұрын

Yep, it sounds crazy but it happens all the time.

Oh boy. Have I suffered this in one form or another in the last 13 years of my working career. XD

This is my life.

I'm technical bankrupt

@tutoriaLinux

4 жыл бұрын

This is the best comment ever.

@sivadasrajan

4 жыл бұрын

@@tutoriaLinux Well, I wasn't expecting this reply 🤣

Snowflakes servers? haha! Have you worked ins the outsorcing service brand for IBM? Half of their customers have at least one old OS/390 as old as the earth. And somehow that old server runs the most critical database, which by the way is also installed over some type of very old DB2 or Informix and cannot be upgraded or migrated because it older than the SQL standard... XD men, I think about that and give me shivers....

Yeah. MVP :/ - Programmers motto no?

Init is so old turn to systemd

Thank you, I didn't knew that problem had a name.