Видео

Wow... Haven't thought about COBOL, FORTAN or PASCAL for years. None of these are on my resume either... because like @acraigwest mentioned... If it ever got out I could use these languages, someone might offer me an outrageous rate to write/maintain this type of code. :-)

Those are the videos I love the most: insights into the actual work!! :) thank you!

4:57 What is "python developer"?

Funny how the programming costs fluctuate. Before the high-level languages, programming was the major headache, as Dee said. It was arcane art. With the arrival of high-level languages, programming became much cheaper than hardware. But hardware was growing more and more affordable, and then at some point programming was against the major cost of a system. And then the LLM AI arrived…

Companies want meetings to feel like something (anything) is being done and tracked.

Good. Agile sucks.

COBOL is easy. I wrote many mainframe tools in university back in the 90s using COBOL. It can still stay in place and have a modern AI layer above. No need to replace it. Python is a good layer that can interface with it. The programmar just need to understand the company they are interfacing that layer with. They have to have all logistic details so that mistakes are not made. AI can help with that as well, if a business model is built for that business. I used to teach my friends in engineering, FORTRAN. As a computer science major, all programming languages were dead simple for me. So it was fun to help my friends, in business programs and engineering. No I was not a nerd, this stuff just comes easily for me. I love computer programming. In the 80s I used to write games and hack the school TRS-80 computer. Who remember those. lol. In university, I reversed engineered Notorn Utilities (and other softwares) to save the university lab from having to wipe computers every night to clean off viruses. I made it do recursive clean state without wiping the machines. My favourite was taking all the DOS viruses apart in HEX/Binary/Assembler, in the 90s and have them interface with Norton.That was fun to watch a virus destroy itself. I never took university seriously, the program was a joke for me, I got bored and left 2 years later. Ended up working for the university for a couple years. Thanks for the video, it was a trip down memory lane... lol

I have been developing and managing teams for a long time and I have done all the processes at this point from waterfall to kanban to scrum/agile to weird hybrids and no estimates. At the end of the day they are all very similar it’s just the cadence of how frequently you meet how frequently you release and which metrics you have to provide. I like no estimates which basically means make your tickets about a days worth of work and skip points and forecasting. I think estimation is often fraught and even with a great breakdown session and buffers added in you don’t know what you don’t know and it’s at best an educated guess. The teams I have been on that worked best checked in every couple of days spent time helping each other solve problems and estimated no more than a month or 2 at a time with larger estimates being taken with a grain of salt, retro when needed and release frequently. That work’s well with experienced devs for less experienced devs you may need a little more process and structure. To me you get to know a team and figure out what work’s best for them and evolve it over time keeping what work’s and changing what doesn’t. I like demos every few weeks because it gives folks a chance to show what they are working on and ask questions about something tangible. I really like in progress demos because if things are drifting there is an opportunity to pivot before release and there is a chance to brainstorm on problems as a team. The key to demos I think is making them a safe place and making sure that comments and requests are heard but also taken as suggestions that may or may not be incorporated and to keep the group small enough so that devs are running it and getting something out of it and feel comfortable. Agile I think has been misunderstood because companies see it as a faster way to get things done rather than a different way and still expect metrics and reports that went with older methodologies like waterfall. So they want you to estimate out a quarters worth of work and hit features by certain dates when agile is really meant to plan as you go and see how things are working and pivot as necessary. The combination ends up being the worst of both worlds you lose the planning pieces of waterfall and get the process overhead of scrum with none of the benefits because you have predetermined all the work and the timelines. It’s hard because I understand why companies want the information because they are trying to plan marketing and report to boards and forecast profits and expenses. At this point I think we need to work from what the company needs and what the devs need and try to come up with some medium that isn’t rigidly adhering to a framework but provides devs time to plan and work together and gives management enough information so they can coordinate with stakeholders. It’s an art not a science and takes time to figure out.

boobs have entered the chat....

Are you actually writing python? I get chatGPT to do about 90% of my python code now.

you're on fire with the content! :)

Except for you not showing the actual making of your coffee, great vid. Seriously though, it’s good perspective to see how you structure and do the work. Not too far off from some of my days (remote since 2005)

This is the best dev channels ever

Funny that none of these advanced coders who resigned didn’t use their skills to develop a SO alternative.

COBOL, COBOL II, Fortran, Fortran77, RPG.....yup, been there, done that.

So programs written in COBOL are safe for AI interference, thats a good thing !

Agile is not Scrum. Agile is about sort cycles, yes. But more about pair programming, TDD and refactoring. Are people doing those tings or is it All Scrum purgatory?

I was hired by my state to program in COBOL. In high school in the 1970s we an alumnus donated an IBM 360 and we could learn FORTRAN. Until we got more memory we could not get a COBOL compiler to run. If I recall correctly, we needed 32K RAM bit we only had 16K so only the 360 assembler and the FORTRAN compiler. So that is all I learned in high school. At university, i learned JCL and COBOL. We did those on Hollerith punched cards First started freelancing and started programming in PDP BP2 and Vax Basic. There I learned ho wo do overlays. Then I got a job working for our state as a COBOL programmer, finally using IBM terminals, although on a screen we still called the lines as cards.I left that job and I moved out of the country.to Japan. I figured that the only jobs where for the government and if I wanted to seriously pursue a computer career, then I had to be on the west coast of the US or Japan. Soon I was programming in C/C++ and Perl. I thought I left COBOL behind but for some reason, although I was a programmer in the C/C++ world of investment banking and mathematical securities trading, then Y2K happened and someone had seen my resume and seen that I did program in COBOL, although almost we were a Sun Microsystems centric company there was one IBM in our New York office. I had to help with the COBOL programs were checked but we got lucky since we had design documents and we got a lot of outside help and rewrote that in C and decommissioned the IBM. I could do all of this from Tokyo but I had to work Eastern time. We got it running with 6 months to spare. So we ran away from it as there was a lot of code that would have broken. Then we got IBM blades, but these were running Linux in New York, London and Tokyo. I spent 20 years in Tokyo and finally returned to the US, worked for a while but now I am retired.

Why would you want a job at Faang? Honest opinion. I would try to learn an obscure language like APL (and then the newer similar languages like J and K) instead and try to get a job in the GPU industry. Or learn a functional programming language like OCaml, or even something more mainstream like Rust or something with a lot of legacy code like Cobol. Anything that isn't too mainstream but something that is still very useful. There are a lot of companies that can profit from those skills and they will not put you through all this bullshit and they cannot afford this extreme hire and fire paradigm when they have not a big pool of candidates to choose from. If you learn mainstream languages and mainstream tech stacks you will always compete with someone in South East Asia that is smarter than you, works 60 hours a week and can do all your work remotely or for subsidiaries or contracting companies. Cultivating good developers in the western hometown of your choice will be a rare business strategy in the future even for Faang companies. But when we look at smaller but still big companies that are the main players in their niche, they will understand that cultivating good developers in their area will be better for innovation than sourcing this stuff out to someone on the other side of the world.

I have experimented with COBOL back in the late 90's on an old 286 PC. I used the equally old COBOL 650 compiler. It was a bit of an experience since it didn't come with a linker. It took a while to find a linker that would work with the object code. Once that was solved I got a few simple COBOL programs from text books to work.

Regardless of what programming language you program in, you should test the program with some kind of data inputted to it. You are going to make mistakes while writing it. You'll want to find those mistakes and fix them. No program should be trusted until it has been thoroughly tested and proven to do what it was designed to do.

Legend 🔥🔥

Before blabbering on something technological, you should state your qualifications. Are you a CS major? What tech products & projects did you work on? Why should we trust you especially when you are not sharing your credentials? This is not Insta. Hope you realize that. Pretty faces don't work here.

In my opinion, Leetcode should be used for only 1 thing. Learning how to code more effectively. It should be used as training exercises only. Not as an indication of how good someone is at a job that has nothing to with algorithmic programming.

For those who don't realize there are still government departments all over the place still use it because their bosses are too cheap to update and as for the rest, If it ain't broke... Funny thing is I can still work out a program in COBOL (surprising how if you learned it way back you still think in the same format)but I get stuck trying to do the same thing in PYTHON.

Megan Markle, I completly agree.

It is not just the language, it is the compiler. Calculations handle rounding under a different set of rules than other compilers. That is why financial institutions are stuck using COBOL.

The foundation of Stack Overflow is flawed. No one should have ever been given credit for their effort. It should have been given freely.

Cobol is self documentimg. They dont have a choice? No. Cobol was & is the choice. Cobol will outlive python programmers. There is a big difference between reality & propaganda. The reality outlived, outlasted the smear campaign of Cobol.

Who would have thought that managers are full of shit?

When I was in us 89-94 COBOL was used

I quite liked Gobol, it's one of the easier ones to learn.

Cobol is just fine, a bit arcance but it works. The mainframe is a high trhoughput system and the transaction systems and databases are huge. It is all very redundant e.g. > 99.999 and therefore extremly reliable. The mainframe will still rule as having many small computers in the cloud is not the same thing. IBM mainframes remain awsome.

Using no-code to build software is like using Lego to build your house, it's fun to do but the end result is not going to be very useful. If your really hate coding, then probably better to learn to get, and pay, AI to do it for you. Though I suspect you're not going to like to that much in the end either. LOL

An example given clearly with description and I like that. Your current wounds are my 30 yr old scars. I like these series of vids you've done - thanks.

Most companies do not use agile, they use scrum. And scrum is nothing more than the classic waterfall-style project management. I bet most people using Scrum have never heard of the agile manifesto let alone read it. In it's core, agile put the developer into the center and management becomes more of a supporting role. And that is the crux of the problem. Managers love to be in charge, to tell other what to do. It makes them feel important, gives them their identity. They want us developers work "for them". Now I am in the unique position where I can just refuse to play the scrum game. The old manager tried to power play with me, told me how I was imposible to work with, how I was not a team player and so forth. So I left his project. And for a full year he had his little scrum-game with new developers, with daily meetings, with "games" to plan times for tasks, set milestones, run sprints etc. They were all great scrum-players, followed the rituals to the T. And after a full year of development... got nowhere. Literally nowhere. So the manager got replayced and the new manager got me back into the project. He tried to get me into the "scrum game". I said no. To his credit he did not fight it. But than again, he did not really have a choice. And now, half a year later the project is back on track, development is in full swing and we installed our first live installation. If you think there is somethign wrong with agile, chances are all you know is scrum. There is no need to go for "Agile 2.0" or whatever you might think, because there is nothing wrong with agile as described in the agile manifesto. The next step will have to be about getting rid of the idea that managers are "in charge". They have to learn that they are not. They are a support role, their job is to make sure that we can do our job. Their job is not, and can not be to tell us how to do our job.

And Tempo time tracking

Your desk seems a little to high. I think your arms should rest in a neutral position and your wrist should be somewhat straight. I've learned that recently. 🤷

Agile is crap.

What IDE were you using for the Python development? It wasn’t Pycharm. You were not using Jupyter either which is popular with Data Scientists.

I can code in COBOL.

LMAO - No body knows it anymore what a load of crap.

Awesome, home office working schedule, love your natural break views. Thanks for sharing, see you on your next video. 👌💪🥰👩‍💻✨💎💃

My employer forced nearly all IT teams to use agile. My team is not developers, we support servers and software on them, along with tuning the configuration of the applications. When we just did business as usual, we were told we were not doing enough Jira stories. So now we have stories for all the little daily things so we can complete more stories. We do less actual work than we did before, but now we have a bunch of meetings and Jira stories to to prove we do work. The meetings are especially a pain. In 2022 we kept complainng because we were averaing 25 hours per week of meetings. This year we are keeping meetigns more under control, averaging about 15, but it's hard because managment keeps pushing for more meetings and we are constantly pushing back.

And those dollar figs -- US$ 800k and 600k -- were with gold at US$35 an ounce. :-P -- about 3/4s of an actual ton (converted from troy to avoirdupois) of gold. By the late 70s, COBOL stood for "Crummy, Obsolete Business Oriented Language". :-P Fortran was still somewhat useful, because, for calculation, it was still particularly efficient. But COBOL was a lump. Not only did it not support then-modern programming techniques (code blocking, information hiding) well in any standard form, but it also was ridiculously verbose in ways that were not very useful. Keep in mind that, in the late 1950s, "Huuuuuge amounts of data, on a large scale" would be WAY less than 1gb. The typical computer even by 1970s had less than 256 *k* of memory, and the first hard drives only held 20mb of data... and cost US$50,000. I recall visiting NASA's computing facility @ cape kennedy in 1978 as part of a CIS trip. We walked through a pair of double door and saw a room with an aisle -- raised flooring (to handle cooling) on both sides, with 15 "washing machines" on each side... _hard drives._ Approximate cost -- 3m to 4m dollars. Approximate capacity? 3 *Giga* bytes!! WWWWooooaaaaaahhhhh!! 😛 As to the "looks like English" desire, I could do the same thing with C and its pre-processor (yes, some people frowned on that). And it would compile to much much more efficient code, even while it utilized major programming rules for writing consistent and understandable code in the timeframe of the 80s (particularly blocking, modularization, and information hiding). There is a reason COBOL fell out of regular usage. *"They don't have any choice."* Not true at all. They just don't consider it worth the time and trouble -- and yes, the risk -- to re-write the systems that use it. Not the same thing, at all. "Not documented"? Who the hell actually reads documentation? 90% of the time it's garbage made for bean counting bureaucrats. There's only about 10% of actual documentation that is useful. And, if you write your code properly in the first place (yes, they didn't DO that back then ... kind of like today) then it self-documents. You should be able to understand everything the code does with that "10% document" while reading the actual code itself. The only issue with COBOL is that it's going to take you 10 minutes to read the 3 minutes worth of code, because COBOL is so ridiculously verbose. It's kind of like writing in Objective C. "Very difficult to learn"? WTF? I had to spend six months in another city when I was a college student ... I said, what the hell, I'll just sign up for some courses while I'm stuck here, at the local community college. "Hey, COBOL! I might as well learn that!" ... six weeks into the course, I find out it's the bloody second term of the class on COBOL. COBOL is boring, yes. It's got limited features, especially for someone used to object oriented programming (it pre-dates that paradigm, like Fortran and "c"), and is, instead, a procedural language, like SQL, which is the closest modern example. ... But "hard to learn"? If you're an *idiot*, maybe. You should not be coding at all, if you find COBOL "difficult". You need to find a wholly different profession than working with computers. BTW, Fortran had been significantly updated even by the 1980s. It's probably been updated *a lot* more since then. Not so sure about COBOL, which probably has a conservative, resistive driving organization, unlike that of scientists. And yes, I'd bet that the real issue with learning COBOL is not so much the language and its constructs as the surrounding sub-infrastructure which is still loaded with mainframe concepts and ideas, as well as organizational practices. Again: Much of this code was designed in an era when machines typically had 64k to 256k of RAM and no more. And may well not have even had hard drives hooked up. For an honest *feel* for computing in the 1960s, do a search on "The Saga of Mel, the Real Programmer".

Nice trip down memory lane. Of course, when talking about COBOL, Y2K should be mentioned (as has been by a couple of other commenters, already). I remember the many job ads for COBOL programmers, during the time leading up to 2000. I thought that was the last gasp of COBOL but here we are in 2024 and it is still a thing, it seems. At uni, way-way back, I had my first programming course. One group had to study and complete their assignments using FORTRAN. Our study group had a hip, young tutorial leader, so we used PL/I. Anybody remembers that?! I still recall one of those assignments, where the star of the show was a sorting algorithm on a large record and we were primarily graded on the speed and efficiency of our solution. Ah, the halcyon days!! The program was submitted on... here comes the punch line... punch cards! Although, we _did_ get the printout of the program from the... line printer. 😂 Those old IBM punch terminals were a pain. The university had limited funding so when terminals failed, repair wasn't instantaneous so we had to queue for the privilege of punching our cards on the few remaining terminals that worked. Same went for the ink ribbons. Reading the hole patterns on the card was a step too far but if you were lucky and the ink ribbon wasn't terminally worn, you could make out a barely visible line printed on the top of your cards. Other times it was totally invisible. It was extremely important to preserve the order of the cards so we quickly learnt numbering them. One guy was in a hurry to sneak the cards in at the computer room before the deadline, so he no time for such niceties. He was running to get to the computer room before the submission counter closed for the day (there was a one day delay to schedule the program run overnight and get the results) . While he was running, his briefcase opened and a large deck of punch cards tumbled out onto the ground and landed as a jumbled heap. Ah, the desperation on the face... He probably still has nightmares about it.

This situation kinda/sorta reminds me of Windows 10... in the sense that many people and businesses will resist being dragged into upgrading for various reasons.

I refuse to admit I know COBOL and some JCL for MVS/Jes3. 😆

Why would Cobol need to support machine learning or AI? Why couldn't AI learn very quickly to program/maintain Cobol routines?

If I was going to migrate anything from COBOL, I'd go with RUST, although very new and somewhat unknown.