September 17, 2019 at 12:00 am
Comments posted to this topic are about the item What You Should Know About Coding
September 17, 2019 at 7:41 am
A lot of the stuff we take for granted these days just didn't exist or was in a fledgling state.
I wish I'd known about "clean code". To be fair, there was a methodology we were taught to use that involved decomposing what we intended to build down to the smallest and simplest components.
I would advise to learn the underlying principles of the tools and technologies I was using. Once you understand the principles everything else is just vocabulary.
I should have read Fred P Brooks Mythical Man Month essays much earlier. Written in 1975 after a career of 25 years (and reissued in the 1990s) there are still lessons in there of relevance, particularly in the essay "No Silver Bullet". Silver Bullet should be the first thing taught to anyone aspiring to be an IT architect.
A lot of stuff from the stuff that Fred P Brooks wrote about is the progenitor of practices we call "agile". I'm keen on the work by James Shore.
If I could talk to my younger self he probably wouldn't listen but I would try and tell him to focus on the way people use the software I was writing.
September 17, 2019 at 12:13 pm
Wow, this makes me think about when I started coding exactly 50 years ago. The way we began was not to write code at all, but to create a 'flow chart' of the entire process, often consisting of many pages of a layout of what was to be accomplished. We all had the old plastic flow charting templates with all the standard symbols which we drew and connected by lines and arrows. Then we would begin writing the segments of of code, in whatever language was required, (Assembler, Autocoder, COBOL, RPG, BASIC) spreading the parts out over a number of sheets so there was room for revisions, extensions, and improvements. Pencils and erasers were the tools of the day. It was hard to push those handwritten lines down to add space!
Once your flow chart was done, the coding was easy because the process was visualized first. It wasn't until my fourth programming gig that we got the first CRT terminals for writing code
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
September 17, 2019 at 12:54 pm
I bought and read the Brooks Mythical Man Month book years ago (decades?). There was one person, Diana, who thought that she was project manager extraordinaire. The first project that I worked on that she managed, if there had not been a federal document detailing the data elements that the system was required to capture, there would have been no functional requirements document. Oh, this project needed to be complete and online in eight months. It would have been late if there hadn't been another programmer assigned to the project. Mike did the ad-hoc reports that she wanted during development; this would have been hashed out if there had been a requirements document; Mike also designed some pages to take some load off of me. I learned during the project that this was replacing a system that a vendor wrote and no longer supported.
The last Diana project was also a last minute project to develop a clean slate system that replicated a vendor supplied system in six months; the vendor had announced that they were dropping support for the system the year before. The former system had over 250 HTML pages with C# code behind. There was no way that a system could be developed in under six months even using the "Nine Pregnant Women Project Management Model" that was mentioned in the Brooks book.
I proposed three plans; I don't remember what Plan A and B were, but Plan C was "Moving Van" which involved taking the hardware from one state agency that hosted the old system and moving it to our state agency. In the end, that's what was done. We took the virtual machine images from the other agency and hosted them.
Diana was a poor project manager. She waited until the last minute to get programming resources involved in her systems. Her meetings were poorly run; she would set up her laptop and projector at the start of the meeting and futz with the setup for 15 minutes.
After that project was over, my manager asked me what I wanted to do next. I said "No more Diana projects" and he said "Done." She disappeared sometime later.
September 17, 2019 at 1:49 pm
Another benefit from those code reviews was learning how colleagues solved a problem. No need to reinvent the wheel if someone had coded it already. Or at the very least, you knew of someone who had dealt with a similar problem so you could ask their advice. Very helpful in the years before Stack Overflow.
September 17, 2019 at 2:14 pm
WOW, Lines of Code. I remember that, back in the day. Never used it, though. I got the feeling it was something done by consultants in order to pad their cost estimates for negotiating contracts. ("That will take somewhere in the neighborhood of 25K lines of code to write, at a cost of …") I'm glad that's gone.
Unfortunately for me, although I've been in the industry of writing code professionally for many years, I've never sat in on any code reviews. Maybe its the area I live in; no body wants to do them. I think it would be a good idea and like the blog post you linked to, Steve, we do spend a lot of time reviewing others code or our own code written years before. ("What idiot wrote this piece of crap? Oh, it was me.")
On the other hand I have been on teams working on code. Its been a mixed bag. I've worked with other developers who are lone wolves; they don't, under any circumstances, what to work with anyone. So, it's a team in name only. But by and large I'd say most teams I'm on have been positive experiences. I'm on a team now with one other guy. We Skype a lot (he's hundreds of miles away from me, so that's how we have to communicate). I get along with him and when one of us have other demands, the other can pick up the slack. Yeah, I'd say that teams are, for the most part, great.
Kindest Regards, Rod Connect with me on LinkedIn.
September 17, 2019 at 3:13 pm
Another benefit from those code reviews was learning how colleagues solved a problem.
I think this is a very important point and very easy to overlook.
No more Diana projects
If you're in this game long enough you'll have worked for a manager where the productivity of the department increases whenever they are on vacation/sick leave. I can remember someone ask "What does 'x' actually do"? The tech lead answered "sows doubt and obfuscation where only clarity and certainty previously existed".
September 17, 2019 at 4:24 pm
High touch leads and PMs are the bane of getting a project done. The best ones give you an outline of what to do and a phone number to call when you need help, resources, or pizza.
September 17, 2019 at 8:38 pm
The best PM I ever worked with used to nudge meetings along, then thanked people for agreeing to own specific actions. If they challenged he'd replay the conversations in the meeting in the way that the majority thought the actions were wisely assigned.
He was brilliant at quietly removing obstacles and calmly disarming explosive situations.
January 11, 2021 at 1:02 am
This was removed by the editor as SPAM
January 11, 2021 at 1:03 am
This was removed by the editor as SPAM
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply