@@GerbenWijnja my quote on the whiteboard would have pre-dated that particular book. I won't claim that I made it up on my own though. Have read quite a few development books and magazines over the years.
At times, producers say we can deliver a product to get funds and then we can refactor, but that mentality sticks and refactor will always be delayed with a similar excuse. On the other hand, usually code can be improved and if we dont set a time limit, things will delay too much not because of lack of perfection, but quite the contrary.
- if you don’t have time to enjoy some coffee this morning, what makes you think you’ll have time to enjoy some later? - if you don’t have time to fix the roof this monday, what makes you think you’ll have time to fix it this weekend? - if you don’t have time to finish that game you just bought, what makes you think you’ll ever have time to finish it? this is one of those deep sounding quotes that sounds smart and deep the first time you read it, but makes no sense the more you think about it.
Sadly the management of projects no longer care about quality. Only getting the product out and letting the user do the testing. Netscape started this back in the 90's and Microsoft put it onto game systems with the first Xbox.
Also, if you're in a code base with irregular formatting and you want to make a clean up of formatting (whitespace and/or braces), be sure to make a commit that only does the reformatting and no code changes. Formatting changes touch nearly every line of code, and if there are logic changes sprinkled in, it becomes very difficult to find them if 90% of the lines are changed.
100% this. As someone who reviews a lot of code, there's little I hate more than a 1 line change hidden in 100s of lines of reformatting. Make the review process as easy as possible for the person reviewing your code. If you use a PR based review process, create a commit and PR just for the reformat and make sure that the reviewer knows there are no functional changes. Then with the formatting out of the way, go and make your actual change and PR as normal. Your peers will thank you!
In the same line of thinking as this, I will often just do a big formatting commit, then PR the thing and get it into the main branch as soon as possible. That way everyone can merge it into their feature branches as soon as possible.
I'm a senior dev and a scrum certified product owner and I can honestly say that many organizations abuse the whole velocity concept to prematurely force developers to "finish" their stories and tasks. They have taken something that developers love (development) and turned it into a sweat shop. So please, respect your developers and stop pushing your team to its absolute breaking point just to meet some arbitrary velocity.
100% agree! Velocity is a vanity metric (looks good, but doesn't really represent truth). I love that term - coined by Eric Ries of "The Lean Startup" book and method.
I'm a senior developer too but you don't need to be one nor be scrum certified to know this. You don't need to be a rocket scientist to know this kind of metrics gets abused.
I've work inside a very large manufacturer, and when I present all of these principles--and try to enforce them on new projects from day one--I'm very surprised by the reactions from other team members. This video assured me that I'm not crazy and I've been doing it correctly for decades... Thank You.
Ofc you're better off starting with principles... Changes cost, rework is frustrating. There is, however, the art of presentation, of making a speech, so maybe you could improve on that to receive more support?
@@Manofry It might work for the next project, but once you have proposed something and management have made up their mind it would affect their ego giving up on their earlier decision, so they will likely choose to go further down that path regardless of how well you present things now...
20+ years of development experience here - I agree with all these points. To reiterate an overarching theme, as a professional developer, do the professional thing and take ownership for your software. Notice the keyword being "software" and not "code" because software is more than just code - it's the documentation, communication, refactoring and timely delivery of that code.
Not just take ownership, but code with others in mind, not just yourself. I've seen more problems with coders going their own way than just picking a team standard and configuring it.
I am constantly amazed by developers who do not produce artifacts during development, no code commentary, no Release Notes, no User docs. AS you state 'code' is only part of the software deliverables.
There’s a lot of selection bias there though. There are uncountable lines of code I’ve written that were 100% throwaway that did, indeed, get thrown away. Being senior means recognizing when you should finish something properly or not.
In Poland in time of communism where people lacked everything we often made such a "innovative" solutions from what was at hand. Here we call such a temporary-permanent fix "prowizorka" from English provisory i guess. Maybe Google pictures can shows some examples for the phrase. Today it competes in meaning with "a crappy replacement" but once was an art of survival & reason for a pride in overcoming headwinds building something from nothing magic. In politics temporarily taxes also become permanent... Satiating short term needs whatever way - because of lack of accountability that becomes a part corporate culture. What proves how illusory democracies we are living in are. The same as in communism - everybody feels all rights to use the public property as their own for own benefit but do not feel any obligation to maintain it, despite eventually still paying for it personally. Laws of jungle. A company with many bosses has no boss & noone responsible for decisions made there. Hierarchy at least provides a stable face to blame. Lack of time, money, resources or will to build long-term in reality are only excuses for those who doesn't care. Owner cares, renter don't. Drifting is always a sign of a captainless ship. Better to be a servant on a ship with captain & prospects than on a drifting ship without any direction slowly consumed, demounted by whoever likes. Equal rights is such a lie.
Also true for many other things. Like moving to a new city and looking for an apartment "for a short time before I find something really nice" and then finding yourself living in this barn after 3 years. Same - to do something quickly and hope to change it latter.
Jamie, This was great advice as usual. I started programming 50 years ago back in 1972 before Structured Programming had been invented in 1973. At the time, it was thought that writing computer code with the fewest lines of code was the mark of a truly gifted programmer. Remember, at the time, many programs were written to be only run one time by the person who wrote the code! This was very much like the Baroque period of music (1600 - 1750) in which Bach lived. So, at the time, programmers were like Baroque composers such as Bach who were commissioned by the King to write a piece of music that was only intended to be played one time at a particular regal function by a single orchestra and then discarded. So there was very little effort devoted to preserving Baroque musical compositions, and that is why we have very little Baroque musical code left for us to enjoy beyond the works of Bach and a few other composers. Only later in the 1970s did I run across "canned" programs that were meant to be run more than once using input data punched on a deck of cards. That's when I learned that "truly gifted" programmers did not write code in the fewest number of lines of code. Truly gifted programmers wrote code that others could understand and work with 10 years later! Regards, Steve Johnston
I really enjoyed your comment. While I haven’t been programming for as long as you have. I’ve found that functional programming, in my limited experience, does usually result in having fewer lines of code and that’s usually a win. Coming from Elixir as my first impure functional language, they have doctests which will be included as an example in the documentation generated and also fail if the function implementation doesn’t abide by the example input and output written in the documentation. So as long as each function is kept small, has a doctest written, and then each of those are composed in order to create other functions which do more things, then the code being written in a terse manner shouldn’t affect future readability or maintainability. The mental overhead of 100 five to ten line long functions is far less than 10 100 line functions. I always try to keep it to 20 to 30 lines max for a function.
@@jamesgood7894 James, Functional programming is much like the programming we did from 1975 - 1995. When Java hit in 1995 everybody dropped procedural programming for object-oriented programming and the C++ programmers just laughed at the rest of us. Structured Programming was invented in 1973 but it took a few years to catch on. Using Structured Programming concepts in the 1970s, we wrote "Top-Down" programs that had a mainline that called lots of subroutines. This was a huge leap from the "spaghetti code" written from 1955 - 1975. In 1972, I started writing FORTRAN (Formula Translator) spaghetti code to solve physics problems. These were disposable programs that were much like solving an algebra problem. Once you solved the problem, you threw the code away. We used single-character variables as much as possible so the code looked like: A=B+C, and I only knew what the variables stood for. When we ran out of single-character variables we would resort to two-character variables. We were punching code out on IBM 029 keypunch machines, so you tried to minimize the number of buttons you had to push for each card because once you pushed the wrong button you had to eject the card and start all over. We would write a few sparse lines of code that way and then jump to some other cards with a GOTO. After the GOTO we would start up again with some new cards with unrelated logic in them. This way we could easily jump back and forth in the code to add more processing by simply sticking in some new cards between the old cards. We did most of our troubleshooting by flipping through the card decks. We never actually saw the code in its entirety until we did a compile and you sure don't want to do a compile because it costs a FORTUNE! In the early 1970s, our compiled and linked executables had to fit into 128 KB of memory or less and that also was an incentive to do very terse programming. United Airlines wrote the Apollo reservation system in 1971 using huge amounts of FORTRAN spaghetti code that ran on the IBM TPF (Transaction Processing Facility) operating system that still exists today for high-volume transaction processing, I worked at United Airlines from 1999 - 2003, and one day I found a printout dump of some Apollo FORTRAN spaghetti code that was still in Production! You could barely understand the code and that is why United Airlines was still running it. So pay attention to Jamie's recommendations when you write code because the code just might live longer than you do! Regards, Steve Johnston
@@stevejohnston2137 Yeah, Structured programming does sound quite similar to the ideas in functional programming. There’s also a book called data oriented programming, which really puts emphasis on the benefits of separating the data from the functions which operate on the data. It just seemed as though the same things can be achieved in FP as in OOP, perhaps not in all cases, but in a majority of them and in a simpler manner. From reading the book on data oriented programming (it was a while ago and I haven’t finished it yet), the author recommends designing your app data in such a way that it’s normalized (think as if you were designing a SQL DB Schema. Then from any function in the application, that large app data can have CRUD operations performed easily by accessing a particular subset on the app data via what the author calls the “information path”. He’s using a dynamic language in his examples, so the information path is just a list of strings which can be used to dig deeper into the app data, which is just a hash/map/object. The author thinks dynamic languages make this an easier process, but there is a formalism in functional programming for being able to handle the same things without much difficulty in a statically typed language. I kotlin has the Arrow library that supports optics, which allow you to access/update/delete within deeply nested data, and there must be other languages which have similar third party libraries which support optics. All the explanation above is to say, if you’re doing the Structured programming idea of top down design and many sun routines, then the higher level functions will normally be passed the large app data and then when the subroutine functions are called, they can either be dependency injected with the app data as a whole and an optics function necessary to accomplish they’re work, or just have the high level function use the optic function to access whatever subset of data is needed for the lower level subroutines. I’ve only worked on one small contract gig and have very limited professional experience aside from that as a programmer. However, I think the benefit of the above is that you minimize the amount of parameters of a function and future changes to the data can be facilitated easier as you’re usually only accessing that data in one location. I’ve heard of the punch card system, but haven’t seen the process which programmers have to go through when doing their work; it does sound quite tedious and I imagine that the need to minimize compilation the number of compilations made due to how expensive it was required a planning and design process that is much more elaborate than many of the places which I might be employed at my current level (looking at startups).
@@jamesgood7894 James, Thanks for your thoughts on Functional Programming. It brought back many fond memories because all the procedural programmers back in the 1990s made the same case for keeping data separate from function when Object-Oriented Programming came along. You will see this many times in your IT career. We all keep going around in technical circles. That is why Jamie's Healthy Software Developer channel is so important because it deals with the people-problems in IT and those never seem to change. I saw the same people-problems in the 1980s, and when I talked to the "old-timers" who did IT back in the 1950s they gave me lots of the same advice that Jamie is giving to you today. For example, in the 1970s we did Agile development because software was usually written by a single person talking to a single business person. Executables had to be less than 128 KB in size so a batch system consisted of many little 128 KB programs strung together with JCL. The little programs read and wrote sequential files on tape. A 128 KB program might read a Master tape and an Update tape and write out a new Master tape that was then passed to another 128 KB program as input. That program would read the new Master tape and do some more processing to maybe flag accounts that were past due. It would then output a new tape with the names, addresses and account information on past due accounts. This kept going until you finally got to the last 128 KB program that printed out past due letters to customers. This was all done in a very incremental prototyping manner without any formal design documents. Then in the 1980s, we were able to write programs that were many megabytes in size and this began to be done by teams of developers. That's when Waterfall development took over with lots of formal design documents created before any coding began. The Waterfall approach held firm for about 20 years until Agile came along again. So it was Agile -> Waterfall -> Agile. I won't go into the details but we also saw Cloud Computing -> Distributed Computing -> Cloud Computing over the past 40 years too. The important point is that IT technology will constantly change throughout your IT career, but the IT people-problems that Jamie discusses just seem to go on and on! Regards, Steve Johnston
Mr. Johnston, thank you so much for sharing this! Not only it was fascinating but also insightful! I'm just a neophyte, but I'll take this one with me: "Truly gifted programmers write code that others can understand and work with 10 years later!". Adding it to my Notion notes so I'll always remember! Thanks again!
I think some of points that distinguish a senior programmers for me : - They know WHY: when you ask a senior why this was done, they will usually have a logical answer, even if you don't agree with it, but their point will be consistent and reasonable, and usually will offer another point of view that wasn't obvious. Juniors and "Pseudo seniors" will usually give excuses, can't provide a consistent answer, or pretty much rely on their authority to push their view. - They have insight: Good seniors can make use of their experiences to predict the different outcomes of different decisions, in a way, they can make mental simulation, and so, they can save their team lots of time and effort by guiding them to avoid future problems, or at least set the project in a way flexible enough to keep going without hitting a deadend. - They are good at handling and understanding business-side: wither it is based on trust or good arguments, good seniors usually know how to deliver their points to product-owners, product-managers, or business users. They may predict the business side concerns before feedbacks, or - They are good at making trade-offs: this is based on the last points, with enough experience insight and negotiation skills, good seniors and tech-leads can make flexible trade-offs to offer the business as much value as possible. - They are NOT perfectionists: Good seniors that "Good enough" is always better than "Expensive Perfection"
Absolutely EXCELLENT points. I did a video called "What really gets software developers promoted?" that is very inline with your observations. If you haven't watched it already, you can find it here: ua-cam.com/video/P3bRQVw6Mrw/v-deo.html
A recommended rule of commenting is that explicit comments should answer the "why" questions and everything else about the code should be built into the code's identifiers (so the code is self-documenting).
@@Raging.Geekazoid I used to feel the same way. In my experience over the past 10 years, this is a nice idea but unrealistic in reality. We've been sold an identifier is enough. I believe we're overly confident in the simplicity of our code. Most code requires at least some comments to help someone other than the author understand it quickly, regardless of how much thought we put into naming. As always, this is just my opinion.
@@HealthyDev Ha ha. In one project, I actually broke down and drew ASCII diagrams of tree structures in a separate text file because they were too big for the source file. So I can't even follow the rule myself. 🤣 I try to though. 🙂
@@HealthyDev I try to usually comment only the "why" aspect, but I do agree that some code does sometime require the "what it does" explanation. It should be used rarely since the goal should be to write more self explanatory code, but we all have different mental models in our head and different levels of experience so that isn't always easy. Of course, commenting "this checks if this is true" above a variable is useless or annotating every few lines of code, but there are cases where few lines of comments sprinkled throughout the implementation is really beneficial.
“Programs must be written for people to read, and only incidentally for machines to execute.” - Harold Abelson, Structure and Interpretation of Computer Programs
I've been a freelance graphic designer for almost a decade. SO much of this is exactly on point. Levels of communication, consistency, and clarity are what really separate the individuals who are a joy to work with to those who may be talented, but I would not want to work with again.
Don't be distracted by language syntax and coding patterns - habits are what makes a senior programmer! Here are some of the best one's I've learned. What are yours? ►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
@@TheCodeTinkerer hey thanks. The music I've been adding to videos since returning from my hiatus are parts from songs I've written over the years. I hope to be putting out some music over the next year or so.
I’m a software development manager and former front-end web developer since 2003, great video and it’s interesting to see someone give their perspective on what it means to be a senior. I’ve been a part of many projects, both brand new development and inherited code bases at several different companies in my career. What I look for when hiring senior developers is a sense that they have some wisdom and experience in what they do, regardless of the language they code in, you can see from interviewing them that they’ve encountered many different development scenarios in their career and they think deeply about what they do. They aren’t too hard-headed, or proud, or set in their ways that they think they have learned everything they need to know, and everyone needs to do things their way because they know best. Humility is vitally important for cultural reasons in a company and also for the success of projects to be able to see obvious pitfalls and roadblocks during development. Over-engineering can be the death of new projects and features. I want my developers thinking about solving the problem as simply as possible from the get-go and only introducing further complexity when it is required. I’ve even done it myself where I’ve tried to implement a new tech stack that I wanted to use, only to get into it and find out it’s adding way too much time and complexity. Usually because the documentation and best practices says that I require a whole lot of scaffolding for my application. This is bad for business. Take best practices into context but still try to solve simple problems with simple solutions. Dependencies create complexity. The more dependency you introduce in a code base, the more chances you will create bugs and add fragility to the project. If you reduce dependencies you will likely reduce the bugs in your software. Also, code so that others can easily understand it and debug it. Even if that means a few extra lines of code. You shouldn’t need to write novels about how your code works, it should be readable and easily understood even for a Junior developer. When code is over-abstracted it can be difficult to track down the root cause of bugs. Personally I’d rather read code than documentation about the code. Abstraction also adds complexity. Anyways these are just some of the things I’ve learned so far in my career, and it seems this type of knowledge is a bit scarce these days (I’m trying to hire right now haha) All the best to everyone out there and happy coding! May your days be bug-free with happy customers :)
I have been programming over 45 years. In too many projects if have seen a rush to produce visible surface results without first building and testing out the functional foundation. This is because management typically has its focus on visible features and doesn't appreciate the art of well structured code. Each sprint should include development of foundation function in anticipation of rolling out features in future sprints. This goes along with your recommendation to bury the refactoring effort so that management doesn't sabotage it.
Couldn't agree more. I learned this hard way during my first role as a senior dev. I was tasked with building new features on top of a poorly written legacy code base. I was turned down every time I mentioned incorporating some extra time for refactor. The company wanted results, and they wanted them fast, and tried to explain to them that the only way to deliver the results they expected was to refactor the project to be more modular and extensible (which it was anything but). So I just said "screw it" and started implementing incremental refactor where I could, without telling a soul. Lo and behold, over time I finally got the system stable enough that we were able to roll out new features at a reasonable pace. The main issue was a severe lack of orthogonality in the code. Changing one small piece of functionality in one component basically meant having to change at least a dozen other components to keep up, and it made everyone's job 10x more difficult than it needed to be. Being an integration engineer can be quite the challenge, but there are ways to handle it.
I have been doing this for a while, its frustrating to be honest. The most annoying thing is when a manager asks what the customer value is of a refactor because its not a feature, but makes a surprised pickachu face if a feature is extremely hard to implement because of coupled foundations that should have been refactored a long time ago
IMHO it's partially, because SCRUM doesn't include a mandatory architecture phase. The success and viability of a piece of software depends largely on it's architecture IMHO. And managers are kids. If it isn't visible no work has been done. If it isn't a large piece of code you haven't worked hard enough (that's why Java was invented). So I tend to write a lot of UI stuff first with mockup functionality, so they have the impression I'm actually working pretty quickly and leave me alone. We already did that in the eighties by making the menu first. Sure, nothing happened when you clicked - but it didn't change during the entire development phase. The sole difference was that at the end of the project *something* happened when you selected a choice.
My second comment on this great video. I met a guy that was working at my old employer, but didn't know it. After being introduced he asked me if I used to work there. I said yes and he went on about seeing my name every day in all of my 20 year old code. Made me feel really good about my work.
As a project manager I cringe about "don't make documentation and refactoring additional tickets because they might be axxed", not because it is wrong, but because I remember how often I fought for these tickets because I knew they would work for me in the long run. (and often got defeated anyway, so you are right)
The problem with this is that developers, especially freelance or contract developers, rarely have any understanding of the commercial side of the business. So, you might think it's being professional to hide this activity and protect management, blissfully unaware they're making decisions about the health of the company based on the faulty information you're providing.
@@RylanStorm In my experience, execs actively ignore "technical" information, whereas devs are paid to figure things out. Often devs are even paid to figure out how to build features the execs already sold because they were feasible in theory.
I really love that you wrote the summary text in the description. I've read the essential parts much quicker than it would take me to watch the video. You are a senior UA-camr for me, many thanks!
I think a big one you missed is to build modular code and dependency minimization. As you get more senior in your programming career and you see both technology and requirements change on at an increasing rate you will really start to value being able to change a piece of a complex software without bringing the whole thing down. This requires building in isolation into your code from the very start since its often an architectural choice, not an algorithmic one. About "unfinished work" however, I slightly disagree. I think more accurate is to say senior programmers get better at knowing where to cut off development. There are just so many things you can do to software post-"it works" phase, like better validation, security, instrumentation, optimization, usability, testability, accessibility... you can easily turn any function into a bottomless pit of development hell if your want. As you get senior, you get better at knowing how much of "finishing touches" does your piece of code/software really needs for the next 5/10 years.
"I think a big one you missed is to build modular code and dependency minimization" - that does make sense, but it can also lead to overengineering and trying to be too smart too early in many cases. I don't know in which field of programming you are, but I work in frontend development and in my (highly subjective) experience from projects I've worked on, there is rarely a need to swap out something super big so that super modular dependency injection design (or whatever) that you might have done is wasted 99% of the time. You'll be grateful that 1% of the time, but bunch of the time you'll potentially be trying to be too modular without any benefit. There definitely needs to be modularity and some abstraction and re-usability in lot of parts, but not everything can or should be super modular. "I think more accurate is to say senior programmers get better at knowing where to cut off development" - Totally agree, I think this one is a big defining characteristic between senior devs and devs that are junior/mid. Senior devs know when to skip something or make a compromise that won't hurt a particular feature or whatever is being developed. They have the authority and confidence to make compromises where needed, but also push in areas where compromises shouldn't be made.
@@tomaszk9210 Not at all. There are two main categories of dependency: internal (the source code with itself) and external (libraries that are used). A large class increases the probability people will start making references to internal variables and methods all over the place, and you end up with spaghetti code that is so interdependent you rather throw it out than refactor it. Dependency injection became popular exactly because of this, it forces each internal "service" to define a clear API and keep its dirty paws off any of your "main" code. Creating code layers and breaking up circular references between two layers is also another popular strategy to minimize dependency. External dependencies are the other category. But this one is easier to understand. You rather call 1 external library that you use 10 methods from than calling 10 libraries that you call 1 method each. At a certain point there is even a case to be made to reinvent the wheel rather than pull a huge external API just to get 1 tiny functionality from it. Common sense applies here, but its all about weighting portability, API surface and weight (especially in web dev), sub-library dependencies, and how complex and error prone is exactly the functionality you want (ex, in security you really don't want a DIY strategy).
About "unfinished work": I completely agree, it's a creative process therefore we could rewrite again and again every month the same code differently if we wanted to. Even the documentation, sometimes it's just a plain english/language duplicated code rather than just a document explaining the whole idea. Also, a senior with experience in the same company should know when it's worth spending time on tiny parts.
As someone who does a bit of Dev and Ops, I sincerely believe your comments about refactoring are very true for the Ops world as well. When there is an opportunity to automate a manual process and it keeps getting pushed off by management in favor of the latest feature, the only way to get it done is to simply do it. Getting that type of improvement work done makes me more excited to go to work, and makes my job and my team's jobs easier.
Yeah, I also believe the management of devOps processes should be within the development team's management, not the business management's management. The one should never "bother" the other. If dev resources don't allow for that, i.e. automation efforts slow down normal progress of a software project, then the organization has a basic issue of manpower that needs resolution.
Yes, totally true. If you realize you have time to make a relatively safe improvement, just do it. Going for permission to do every little thing just wastes everyones time and just shows you cannot make decisions on your own. Of course don't go willy nilly just changing everything, but doing improvements when you know you can and have the resources is good.
You try to stick to standards and patterns and principles but the rest of the team does whatever they want... then later down the line they say we have to re write everything and they rewrite everything in another framework but still dont stick to any architecture or standards 🤣🤣🤣
@@BillClinton228 Ya I hear that as well. It's hard to stick to standards and do things the right way. It's easier and faster to cut corners to get the job done and make the customer happy. The problem is, that the next project/task/ask is going to be that much harder to deal with, multiplied by the number of other people on the team. And hopefully nobody on the team left the project and didn't document properly.
Great video! I would add that truly senior engineers not only enforce testing standards, but they also enforce standards for logging. This includes defining patterns for how logs are written, and standardizing what types of logs are used in different scenarios.
First point about not doing that extra cleanup at the end, if you push it off most of the time, most orgs will blame you later for creating tech debt even though they discouraged you to do the thing up-front 😂 always clean.
I've been fortunate enough that almost every project I've been on has been managed by somebody who used to be a developer so putting jira issues in for things like refactoring and documentation and other things we know we need has never been a problem. If, however, your manager hasn't worked in the trenches I can definitely see doing the work without creating a bunch of jira issues.
To me reviewing pull requests properly is one sign of a senior developer. I've seen so many PR's where other developers just approve the changes without really properly reviewing and testing the code, whilst I do and end up finding lots of issues (readability, lack of comments, not following coding standards, bugs, etc...). This is especially important when less experienced developers try to get some changes into the development branch. We as seniors are gatekeepers who must make sure that bad code doesn't get in to development, and if we are lazy and just write "LGTM" then surely the quality of the code will decrease over time.
I agree and other developers really appreciate it when you provide valuable feedback on their code. At least the good developers do. I do think it's important when you provide feedback on a pull request that you do it respectfully and constructively.
Lol Gatekeepers... some of the worst I've seen were written by seniors. Many young developers are impressionable, older developers are already set in their ways of writing alien Cypher as code. Lol
@@igboman2860 In my experience most senior developers are actually not senior at all. While most people who are given the job of being gatekeepers are unfortunately unqualified - it does help to have a qualified person help level up the skill and quality of the team. Unfortunately with modern hiring practices that's getting harder and harder since we keep promoting young and inexperienced engineers and the ones who finally really do learn the ropes leave because they're tired of the politics. We can do better as an industry!
This is one of the biggest gripes I have at my current company. Most people will get a notification about a PR and it's approved with no feedback within a couple of minutes. At least a couple of times a week I have to call a halt on a PR that's already been approved and potentially merged because of some glaringly obvious flaw.
@@Corrup7ioN yeah that's quality theatre. The appearance of quality but just a waste of time. I've been on a project where we had to stop doing PRs because they were giving us a false sense of security and not really adding value. If people don't really follow through it's just process overhead.
I'm not even close to being a senior dev, but I found all these points super inspiring to take on. Very nice guitar interludes as well! I had started the video in another tab and was just listening to the audio and thought "ah, nice music" but didn't realise until I switched back at the end, it's actually you playing...! Totally dropped you a follow!
I think putting together good commits is an often overlooked skill that can make code review 10x easier as well as being something that can be referred back to when getting into a codebase for the first time (or indeed the 10th time). Making sure that commits are granular enough to be digestable as well as conveying intent properly rather than just a list of what files are changed and a wordy replication of the diff.
I've heard this a lot in my career, but I cannot relate to it. When I'm looking at a pr, I'm only interested in viewing the change as a whole. I don't care about the sequence of events in that developer's personal process of coding. I just want to analyze the code quality, which is unrelated to commit history. So I almost never find it helpful to look at individual commits in a pr. I look for usages to see why something was added. I think the pr description is the place to explain any justifications for arbitrary implementation choices.
@@megamaser different strokes for different folks i guess, unfortunately for the team i'm in that approach doesn't work as we are responsible for 20-30 microservices with disparate codebases. When your familiar with a codebase because you are in it a lot then i completely agree, dividing the pr into commits doesn't provide much benefit as you already know how the application fita together and what files/functionality needs touching to add featureX. and while i cant speak for anyone else, my brain won't hold 20 odd codebases in my head so breaking it down into commits (especially if logically structured) allows me to cut down on the 'refamiliarisation' time rather than starting at int main(int argc, char* argv[]) and working through the main flow each time till i figure out the needful. Its also courteous to other developers who may not have worked on the codebase in a while. those who find it useful find it very useful those who dont havent lost anything due to having granular commits as there is always a method to view the feature as a whole.
Agree, it's the first thing I look for in the project is the source control history. I take pride in writing detailed and useful commits because I understand how important they are not only for you but for your team.
One more thing to add to the list: always try to really well-and-trully understand what problem you are trying to solve, how your language/frameworks/libraries really work, what is _really_ going on
If I'm using a library, I just need to know a bit about its internals, and then just trust the APIs, right? The whole point of using a library is code-reuse, plus the abstractions it provides. If I start understanding the library 'fully', won't that be needless time-sink?
@@balu.92 About the libraries: I think it's more about knowing what the library can do and knowing what it can't. So getting familiar with the documentation and knowing more than just the 10% of the features listed on the "getting started" section of the library's documentation. Example: I was working on a project where a certain library was introduced by an external team. It was a very big and powerful library, which offered much more than what we needed, adding quite a bit of complexity. That's ok, but some of the functionality that the lib offered, which we could actually make use of, was then again not used but rather implemented by the external team themselves. That to me was a case of "There is a lib which looks like it could solve our problems, but we couldn't be bothered to get really familiar with it".
Development is also explorative work so you never truly know the problem-solution space until you implement it and then refactor it and then you find ideas how to improve it... Only after many iterations you truly grasp the problem and solutions and rarely you know it before you even start to write the code.
I'm a mid-level engineer at this point in my career, and I picked up a lot of these habits early on, purely out of annoyance at the engineers' code I had to work on who used niche, complicated, hard to work on, and mostly undocumented structures and patterns. I think a lot of programmers fresh out of college will go out of their way to use weird quirky methods that will impress a FAANG interviewer like unneeded lambda functions, overly complex ternary operator statements, etc, without thinking about how they're gonna read this same code a month later, let alone somebody else reading the code and trying to add to it. Now I'm gonna be in charge on a brand new repo (that isn't only me contributing to it) for the first time, and I'm hoping to get all this stuff right lol. Thanks for the great video.
When you, who wrote the code, can't understand your own code a month + later without spending a stupid amount of time on it, you are doing it wrong and "They" are also to blame.
*Junior programmer:* _Uses fad parts of the language because they can._ *Senior programmer:* _Uses specific parts of the language because they need too._
I worked at a company where variable names were written in English, in Portuguese and even in both languages. Also, there was no code style, so everyone used whitespaces differently I warned my boss about it, and a bunch of other problems, then I got fired. I'm happy seeing how you value code standards...
I had to ban pluralized variable names on my team because the english, portuguese, and spanish speakers all used different pluralizations and ALL the plurals confuse the crap out of the 2 chinese speakers we had on the team. Language can create some real headaches.
Hey nice guitar skills! I have two extra habits: 1. Reason the code in the smallest increment that adds value. 2. Fix the past before continuing into the future.
Being proactive rather than reactive is also something I see in response to senior development. Thinking ahead, asking the right questions, coming up with a plan rather than just diving head-in and fall into the trap of following the task step-by-step like a robot. It helps keep tech debt to a minimum, speeds up the overall process as you might not have to go back and forth 2-3 times, and it also tells management that you actually have some deeper understanding as to what is going on in the business aspect. Establish a good communication flow with management. It will also help when more junior developers come to you for guidance, because you now have the extra insight, aside from just what you know in terms of code, patterns etc. You'll also have the "why" is this feature necessary, "why" is the user flow the way it is etc. etc. Taking reins when necessary. Stepping up to take directional leads when needed, being able to coach the team, being able to brainstorm or at least present options or solutions to problems you discover either in the code base and/or otherwise, is also something that makes you stand out as senior. Owning a code base. Having a specific portion of the project that you specialize in, something people come to you for advice in is also a good indicator for seniority. Senior devs are so much more than just the code they write.
You're assuming that you know what the 100% actually is, which is rarely the case. Getting most of the way there is often "good enough", at least from a business feature perspective, and pushing past 80% is usually wasted effort. People realize they didn't want that after all, and want something slightly different instead. I'm talking about user facing features, and not internal infrastructure. If you cut corners internally you're going to have a bad time.
User facing features are built on the internal infrastructure. You really should make a great guess and do the ~100% even if the last 15% are a bit off as they take a very short time to do so. Eventually those 15% are going to add up and not many developers would want to complete an almost done feature vs fixing minor bugs or doing small alterations, it would also result in an unpolished product. But then again, sometimes there are more pressing features and the 80% should be enough. In most cases, I don't think that's the actual case.
Thank you very much for your new video! #1 is just the exact reason I abruptly left my last position being burned out and down to nothing. I was porting some old code and because I'm dumb and hate reading spaghetti over and over - I chose to attempt to do it the right, SOLID way with levels of abstractions and all that, but occasionally faking, stubbing and throwing some eye-candies for leads/managers asking to "stop fancy-coding and just do it whatever, so it just works" because a schedule of biannual product releases. As the time went the chasm between my private progress with unravelling an old ever growing 'big lump of pasta' code and the one I gave impression of grew wider. And eventually I understood that it will never converge and now its probably too late to ask for help (task underestimates, everyone) and then something just died inside of me and I resigned. I'm somewhat proud of what I was able to achieve in compartmentalizing pasta pieces and some interesting things I managed to do, but I'm afraid most of it might just go to waste :( But I am being more and more convinced that writing code in such way that if you read it aloud and it would sound like a plain English spec text - it's is the sexiest thing for me, honestly.
"I am being more and more convinced that writing code in such way that if you read it aloud and it would sound like a plain English spec text - it's is the sexiest thing for me, honestly." Gherkin and ruby!
I have started to follow your channel from few months back. Your videos does reflect day to day shenanigans in life of a software developer. It really helped me to see the bigger picture of corporates from a bird eye view. Thank you for your efforts and appreciate your content. 😊
It's interesting how the main take away here is more to do with organisation and communication rather than actual code. Being professional means taking other people into consideration, listening, and patience. Great advice!
This is really solid stuff. The only thing I'd add is to practice having the mindset like the following: Bugs don't exist in code that doesn't exist. Nobody spends time maintaining code that didn't get written, so unless you absolutely have to do something, don't do it. A lot of developers suffer from the "newer way of doing it" mindset where they change things for the sake of change, or because it's new and gee whiz or they introduce a more complex way of doing something when there's already an existing tried and true pattern that is much simpler and easier to maintain. Just don't. Unless you have a really good reason for doing so and it's been vetted with the rest of the team. I say this because all too often (myself included) many developers consider it a badge of honor to have a big ole' fat stack of code that they wrote with a bunch of gee-whiz stuff when they could have easily implemented the same feature/functionality with a much simpler tried and true pattern that is easier to maintain and less bug prone. I can't tell you how many teams I've been on where I look at the actual end user functionality and the amount of code in the codebase and come away going "that's an awful lot of code for what it's actually doing", then get into the code and find myself constantly going "Why is this being done this way? I can't see any good reason for a lot of this code to even be here, because now there's a bunch of code to maintain that isn't actually doing anything towards the end goal, or is doing it, but can be done in a significantly simpler fashion using less code that is easier to read, understand, and maintain". It's like a sickness many of us have.
I thought the whole idea of engineering was to make things easier. My coding practice has been all about that - if I can find a quicker way to make some process happen, then I'll code it. If my code isn't efficient, then I'll refactor it (usually because first pass at a new concept isn't the best way). I learned in the pre-OOP days, where everything was essentially scads of scripts. Once I learned OOP, I was able to take some of my older code (that was still in use) and make it do more toward what it was intended for, with less code. Still, if it ain't broke, don't fix it. And when requirements change, make it better.
@@l00k4tstuff you should always refactor your code to make it clean and you do it not for efficiency but for readability so next time you or some other programmer will have to change you will understand it faster and you will make the change faster.
Been watching your videos on and off for a little while now; but as a junior developer who's less than one year in my career, this is really helpful. In a way, it's also validated some thoughts I was having on how I should develop my projects. Thanks again for the tips!
Great, love it. #5 never expose refactoring, I know Martin Fowler in his book "Refactoring" advises that we don't need to ask for permission to refactor. It's part of the job. You justify refactorings by claiming they are necessary as an indirect part of some other user story or bug fix. But what if you want to refactor and it isn't tied to some specific user story or bug. Now that can get tricky, because in most organizations you need a branch and a PR to make a change, and that requires you to reference the ticket you are addressing with the PR. And you're right, often times your manager isn't going to approve it, and that means technical debt is gonna keep building up in the project and that sucks. My manager was a stickler for vertically sliced user stories and the INVEST criteria. So I got good at writing them and came up with some clever verbiage to justify work at the user-visible level. If I was really stuck, I might write something like: "As a user, I can enjoy the benefits of a more symmetrically streamlined database schema, so that I can receive higher quality software updates faster." Usually I didn't need to resort to that, I could write it as a more direct user benefit, but dang it all, I kept trying. The one thing I finally got praised for there was writing good user stories.
It sounds like you're really good at writing user stories. And in an environment where the value of a story being "a more symmetrically streamlined database schema" is understood by the management, that's awesome! In other situations, the cost of implementing features for a business includes paying back technical debt. It's just built in and never helps to expose to people who aren't qualified to understand the implications of foregoing required refactoring. Notice I said "required refactoring". I think the reason some managers try to stick their nose into refactoring where it doesn't belong, is they've been burned by prior unnecessary refactoring. I understand their pain. But it's a mistake to expect us to surface everything we do in the context of a user story just because some folks have been burned in the past. My two cents as usual!
I usually put this kind of task into separate tech debt and try to map which tech debt can be mapped to what feature we want to plan in the near future (at most 3 months). I also tried to put the JIRA ticket on each code that we should refactor so instead of TODO REFACTOR THIS BIG CODE just put DEBT-1919 so if somebody sees that and working in the current feature and the ticket is waiting to be done, they can pick it up if they think they also want to refactor.
Yes, the code should be self explanatory 😂that part just made me laugh, whoever said that has never designed or implemented any complex production software. On Incremental refactoring, dying so hard for refactoring for long, I am going to try that and see if it can pass code reviews, great job this episode!
Really like the tip about taking full responsibility for refactoring and doing it incrementally as a team. Something always bugs me when another person says "let's take one or two weeks to refactor this part". This gave me inspiration to handling that situation.
As an electrician, I'm always doing my work with the knowledge that someone else later on will come across it and will judge it. And even though there's no real accountability to me personally, I still like the peace of mind & feeling of a job well done, and the knowledge that whoever has to maintain it behind me won't be cursing the whole time. Another parallel I could draw from something you said previously, was being pressured into doing work you know is not right. If I were to have an employer (electrical company) try to pressure me into doing work that was unsafe or against code, I would instantly lose all respect for them and start looking for work elsewhere if they held fast. If it was an employer who was unaware because it wasn't their field--like a general contractor--I'd explain it to them that it can't be done that way. At least I'd always have the electrical code to fall back on and an electrical inspector to back me up, which isn't really an option for programming.
I think that's just the point the OP was getting at and it relates to any professional tradesman, craftsmanship and following high quality standards. Everything should be done perfectly whenever possible and when not, it should at least be very unlikely to introduce hazards or difficulties and a plan must be developed to remove the obstacle to perfection as soon as it's practical. As a former military aircraft electronics technician I actually left a VA "preferred" coding boot camp shortly after the CEO described the software industry as in such dire need for developers that, "you just have to suck the least." That mentality manifested itself a few weeks later in the boot camp. College was enough of a fool's errand for me and I wasn't looking for the same experience on steroids. I'm still interested in coding, but I sense there's a major down grade in craftsmanship going from aerospace to "tech'" (that term is a misnomer anyhow, because software is hardly the entirety of technology--thank God!). I guess when your product only figuratively crashes, and no injury or deaths are likely as a result, the "time to market" principle can be front and center. I know I know, but what about medical equipment? If you leverage the speed and convenience of software, great! If you make your clinic unable to operate in the absence of software, which fails much more frequently than hardwired electronics, with patients' welfare in the balance, you have no business running a medical center. Microsoft hardly had a better OS than anyone else, they just shoved their crap down the world's throats so quickly, everyone who is not a computer scientist has to use Windows to run a business or believes that they do. People ran businesses with carrier pigeons and abacuses, long before Ben Franklin got out their in a lighting storm with a kite, so let's not overrate "tech" as a necessity. Tech's purpose is to generate profit. If it did not do so, no one would be employed in the field.
Just started my first job in tech as an SDE intern, and I am learning that there is a lot more to it than just coding and making things work. This is a great video, Thank you!
Focus on becoming an amazing programmer first and don't get dragged in by the 'water cooler talk' in the first few years of your career. I've seen so many juniors stagnate because of this habit. Also, there is loads of documentation and learning material just in open source projects. Good luck with your career and have fun!
At first I was skeptical because of the title. But I agree with most if not all of what you said here. It's tough to find something that actually explains everything beside the code itself, so it's no wonder why there's a lot of developers who don't know about these things without 10 years of experience. This is a valuable resource for those who wish to become better collaborators in a team.
The approach for clean, readable, maintainable code also applies to any related project documentation, whether that's high level designs, low level code specs, test plans etc. The mantra I have is... don't write the (what ever the deliverable is) for you, write it for the next person.
A lot of it boils down to, senior developers have discipline and instill that discipline in their team. This could go for just about any profession. A true expert has discipline.
A couple of my favorite senior programmer proverbs: • keep it super simple. the easier your code is to read, the more overlay between your code and other languages, the better. • reduce function points. that is: 1 boolean clause is better than 2. equals is better than not-equals. 1 paragraph is better than 2. 1 parameter is better than 2. etc... • please avoid fanciness. again. i've coded in some 30+ languages by now. the world changes. it's best NOT to leverage every single corner of the feature set. • comments and doc-strings, please. • understand when to stop abstracting. if something can be decided by a single `if` expression, it may be too early to create another child class. • and it's not as relevant as it once was, but "eat your own dog food" - that is, be your own best customer. learn to automate aspects of your own job. when you can do that, reliably, you can do more; which is what computers are for, after all.
I just started my journey to become a software developer at the age of 44. Every tip or habit i can implement into my work, i am truly thankful for. Thanks for sharing this with us.
Any team project, programming or not, where you're discussing things and making decisions, it's really important to document your intentions with your chosen action. Then also document why the choice was made, what else was considered and why it was rejected, and ultimately what the pros and cons are for the choice you made. Your decision might ultimately be wrong, but it helps get people to speed very quickly, yourself included months or years later when you come back to revisit the results of a decision and can't remember the meeting. If you can see not just what was decided, but why, and what you were hoping to accomplish, that's useful data points when you come back and have to change things later. It also helps when you think you've got a new idea for a change, but the implications were already worked out and your new idea is actually a rejected old idea, maybe rejected for good reason. This all comes down to really good documentation practices, but many people make the mistake of only documenting what was decided with none of the associated reasoning and intentions behind it.
It's the difference between documenting i++; // increment the i variable" and sessionCount++; // update the number of active sessions They're the same code, just the second one lets you know why they're doing it
I hear a lot from 'senior' programmers saying "I don't need to write documentation, I write self-documenting code!" What they really mean is that they believe their code is easy to read, and if they are good, it's probably true. However, documentation, especially the WHY something is done is incredibly valuable especially down the road when you haven't looked at that code in 6 months, 1 year, 6 years, etc. Just recently found your channel and I've been enjoying your videos. Great work!
Really liked point 5. I did a major refactor of a small module several months back. My instinct also told me not to raise the point to the project manager as they would reject it / not want to spend budget on it, but I knew it was necessary. However, I am not a part of the budget negotiations and wasn't able to allocate extra time buffer on other tasks that I could use to spend time on the refactoring. I think that was something I needed to make more clear in hindsight. I ended up squeezing in the refactoring, but I probably spent at least 40-60 hours of my own time over the last 6 months of unpaid overtime to complete the refactoring. It was ironic, because even as I was refactoring it, we were getting tasks that required new extensibility which was only possible because I had already partially refactored the older limited code. But unfortunately since I wasn't a part of these talks, I wasn't able to communicate that refactoring would be necessary and therefore more budget. But it was definitely a good timing initiative on my part to have begun it before then, so we could even complete the tasks at all by the deadline. Still, it's something I need to manage better next time, so it was good to hear a possible structured approach here. I really liked the idea of discussing ways to spread it out over the upcoming tasks, and also the verification that it's better to not leave the decision up to the project manager by telling them you want to refactor. I was a bit torn on the matter as if I was secretly doing other work that hadn't been formally requested yet charging it to the budget. I think in the end though it turned out to be the right decision. Also, the guitar is relaxing and fits the theme of maintaining a destressed, healthy mentality. It's a nice touch to interpose it now and then.
@@alexisfrjp I learned a lot about the code I was working with. I don't do overtime unless its a project I'm interested in, basically something that can teach me new things.
Big fan of creating a UI and code reference project with fleshed out, working examples of the tech stack, UI design, patterns, and shared libraries/services. This can act as documentation along side being a working example of how all the moving parts interface. I find this far more valuable than just a wiki of documentation, diagrams, and isolated code snippet examples. It saves a lot of time on boarding and not having to answer lots of questions about how parts actually work together. It also reduces the amount of documentation you need to write because the code speaks for itself.
Documenting and reviewing the chosen design patterns is a very good point. Many devs just use them intuitively or not even realizing it, while others just don't get it why and where and what.
I just found your channel. Really cool stuff, thanks! I disagree on the refactoring though: a) It's strange idea that management is by definition unreasonable. b) Refactoring tends to break things, so it's better to refactor one thing at a time, so it can be tested. c) If something was broken by refactoring, and there is no ticket, it will take more time to investigate. d) The approach of spreading refactoring on other tasks creates dual time tracking and kind of uneasy conscience. The approach I use: if there is a task, clean the stuff around it, as it will be tested all the same. If there is a potential of breaking things outside it, open a ticket and discuss with management when there is the right time to do it. Formulate it in terms understandable to business: less bugs, better performance, easy to support, etc. Because "refactoring" without details may sound fishy to business. I absolutely see their point of view. Especially when it comes to young developers who just eager to try all the possible libraries, patterns, approaches, etc. and then leave for a job with higher salary.
I agree. I've experienced management of "varying maturity" for managing software development, and I find it also depends on the load on the team and project deadlines. In my experience, refactoring can become a hot topic, that makes management (and customers) uneasy, because; - even the most crappy code has a somewhat known behavior, while if you think about it, newly refactored code is just as prone to errors as green field code, even if the code structure is better than before, and some old errors have been fixed. Introducing risk into a project or product without informing management can put them in a bad spot in front of the customer, and decrease their trust in the developers. - some developers feel the need to refactor, because it is easy to see what the current code is not able to do, but often we miss what the existing code might actually do very well, or some special case scenario handled, and that does not get translated to the refactored code. I find we can sometimes be a bit too confident in our abilities to really understand what we are refactoring from. - I've seen customers reluctant to upgrade, even if their current version had bugs, because random stuff always appeared to break in the next version, with no notes of a change in e.g. the release notes. - I feel we as developers are not always great at conveying the absolute necessity of a refactoring in a way, that makes sense for the business, but end up just being annoyed with managemen for not respecting our opinion. But the arguments presented often sound like "it's just better", "it looks prettier", "we've wanted to do this for a long time". I believe that a professional senior developer is able to explain and motivate a change for a (somewhat reasonable) management - explaining how a refactoring can decrease risk, improve performance, scalability, flexibility in features, reduce cost per feature for future tasks, etc. are perfectly valid, as you say, and if they can not be identified, maybe, just maybe, the refactoring is actually not warranted, and is more of a personal preference. - I've also seen very experienced developers promise the business some improvements on a very expensive refactoring, that didn't actually happen / pay out. No sensible management will or should want to allow a refactoring after a stunt like that for at least a while. That being said, refactorings are definitely necessary, should probably be done in small increments (maybe using e.g. the boyscout rule), and yes, in the end we the developers need to take responsibility for the code, and in that, do for the code what we see fit to hold that responsibility.
I think your comments are interesting regarding refactoring. I think people generally accept that refactoring happens without tests-you rewrite some or all of the code and just hope that all the logic is basically the same. But even though this is how people generally perceive refactoring, the books on it (including Fowler’s Refactoring) describe a rigorous process of placing components under test to pin their behavior and only then restructuring the code. They also talk about doing this for good reasons-maybe you need to fix a bug or add a feature, and to do it you need to add tests, and to add tests you need to refactor. If we were all using the by-the-book definition of “refactor”, I don’t think it would even be a conversation, and we would naturally be satisfying the aspects of refactoring that you like!
With all respect, but I think most management is mediocre at best. In my 40y career I've only seen four very good managers. The rest is completely clueless or needs vast amounts of pampering to get them into gear. So no - I don't think it's a "strange idea". It may be true that most managers consider themselves the best thing that hit this world since sliced bread - but that is a misconception. Refactoring doesn't break code. As a matter of fact, less well factored code will break more often and becomes more and more expensive to maintain - according to a Bell Labs report. Every programmer knows that you change one thing at a time - just to prevent such an occurrence. However, "refactoring" may hit a large amount of code - that's WHY it has to be refactored in the first place. Hence, the effects may be wide spread. The rest are just consequences of dumb managers who don't understand that internal code quality is essential - now and in the future. And if you're stupid, yes, those are some of the consequences you have to bear. Trying to put that on account of the guys who have some pride in their work is one of the tricks stupid managers will try to pull in order to keep their position and save face.
I've been a consultant for 25 years and I hope youngins watch your channel and learn. I'm not a developer, but I know everything you say is spot on. Especially documentation and standards.
I know this isn't technically writing code directy, but it effects it indirectly by writing less of the wrong code, so I would add "asking alot of questions", including possibly stupid seeming ones, both in general but especially during any planning/design/anaylsis. Drilling down into things like customer requirements and possible design issues early one can often uncover and solve problems before they even arise. This can save a ton of time by simply not having implemented unwanted or unworking code in the first place or having to rewrite code multiple times, because you just keep discovering that there was a little more to it. It can also push the customer into analyzing and defining requirements more completely and earlier, like when a question they haven't even thought about yet comes up.
I agree diligence is a good attribute of a good programmer. I think debugging code is important as well. And I guess it works for the overall process, is to move in small increments, fix one thing, write a little bit of code, watch it go green, or how ever your team does things, just don't do a lot and forget where your going. I know when working on personal projects, there are two versions of me, one that just starts banging away on the keyboard, no commits, no tests, no refactoring, and 200 lines later I got soup. Then there is the me that opens a branch, writes a little code, commits, checks it out, refactor, maybe I push it, rinse and repeat, ...the point is going fast usually never works out , go slow and diligent and you will go well.
As a retired software engineer with about 40 years experience I agree with most of what you say, especially about continuous refactoring. On one big project (about 6 million lines of C++ back in the early 90s) we did a 3 month release cycle and the QA team decided to look at the check-in rates. They found the average team member checked in around 3000 lines of new code. Our most senior programmer checked in -5000 lines - yes, 5000 lines less than he checked out, while adding serious new functionality. He also published a checklist of refactoring items that other teams should apply on future releases but with no use-cases or user stories etc attached. Just good practice.
@@hicknopunk A full build took between 4-6 hours. We used a home-brewed distributed build system across 4 Sun servers. Not the longest build time I've worked with, that "honour" belongs to a PBX control system built on a DEC Vax which required over 24 hours. It was built over the weekend once a week...
I noticed that some of the pointers here such as incremental refactoring and documenting patterns have recently applied to me and I think it just stems from thinking about reducing technical debt such that time can be spent on implementing features, and making it easier for the team to work across various code bases. This is an insightful video, thanks for sharing!
100% agree with everything you said. Its tiring working with developers with 10+ experience who don't get that those abilities are the most important. A developer is a digital counselor, not a simple programmer who should copy paste the best standards just because others say this is the "best thing" to do. You should ALWAYS have a sense of "technical diplomacy" . It's about having a minimum of professionalism in my mind. You can't be a good developer if you are not: transparent, critical, capable of putting yourself in other's shoes, thinking about business implications of what you do, blindly thinking about "best practices" without looking at the actual needs and how to transition properly to the proper solution.
It's pretty much totally unprofessional to lie about what work is needed. And lying is what is being advocated in parts of this video. It's no wonder programmers have difficulty being taken seriously. If major refactoring is needed to make a new feature easier to implement and more reliable, then that needs to be stated explicitly. Pretending a feature is going to take six weeks because it requires massive documentation and weeks of refactoring isn't helping anyone.
@@loganmedia1142 You didn't listen to the video properly. Listening to the "prevent unfinished work" he says to be straight forward and explicit about needs. 2- Programmers have difficulty being taken seriously because they speak in "geek" terms without caring enough about who the listener is and how much they understand. Also developers are known for being very "needy", because many don't want to do anything but code (which means no documentation, no recruiting, etc...). Because most are too "focused" they lack vision and proper understanding of the priorities. I'm a programmer, I see it every day by experience how much developers disdain proper documentation and thinking about those who are less experienced then them. 3- As for refactoring, you might think its not professional to not say anything, but in my opinion its the exact opposite given the current reality. The reality is most projects are managed by people who don't care about tech and THEY decide what you do on a daily basis despite most of them lacking the will to understand your point. So why would you waste time trying to explain and get your ideas validated by people who will never be able to truly measure the issues until its too late ? Just don't , its your work, you own it, its your responsability so stop asking for validation and just do it ! I rather work with a developer that knows how to take initiatives and makes mistakes, then a programmer that does nothing except what he is told and does it well. Because the first goes way beyond just giving advices, you can trust them to tell you when things are truly going bad because they will only talk to you when that is the case , while the other ... lets just say you'r already lucky if they give advice (not to mention its usualy bad advice most of the time because it lacks corporate vision, so they wait for your approval every time making their boss responsable for a work they don't even understand most of the time ). Professionalism isn't just about transparency, its also about knowing when to take risks, and its actualy this very risk taking that shows the difference between an inexperienced and experienced developer.
love the points you make in this video, there's a theme of patience and thoroughness running through all of your tips that just exude wisdom. what especially surprised me as a junior developer is hearing how universal some of these things you describe are, I found myself thinking yeah, there's people on my team who have done this or that and I've definitely been guilty of a couple of those things (especially the being done with 85%-90% of the work thing but saying it's done thing! wow)
Don't be afraid to go back and add more tickets/stories as you discover things that were not captured in the requirements or we're missing. You always have to make sure every requirements, changes are captured in the ticket. If it's something small then you can just update the ticket and inform the requester before working on it. Yes your scrum Master may not like it however it will help him understand how much work you're taking on.
I totally agree on this. Even if it's technical debt. That's because any change in the code has potential to negatively affect a functionality. By raising it as a ticket, the affected functionality could be QA tested. No bug suprises because of untested code. Unless, your code has 100% automated test coverage.
I just love these topics you have man. They're day to day experiences I have and I can't really talk to anyone else about them in my life. Glad it's more frequent than I thought.
1, finish the task, good call, you will never have time to go back. 2, write tests, tests, tests, tests and more tests! 3, write readable code 4, never ever give a full estimation, just give an estimation on the first deliverable feature, that includes time for unit tests 5, more tests, this will save you! Formatting, patterns is something is a company thing that’s usually already specified. Generally, you should follow the formatting, code style of the codebase you’re in. unless it’s your task is to rewrite it. Focus on writing good code, good test, let it known that you will not be available for sales meetings. Once you start wearing a few hats, you can’t focus on code
Some observations I've had over the years... First write the program/feature without writing a single line of actual code. Plan the structure, objects, interfaces, patterns, etc. ahead of time. Once you know how the code is supposed to be structured and function, then write it. After years of writing code you find that "writing code" is the easy part. It's the thinking/planning/designing/structuring/etc that is the challenging part. Do that before you write anything (besides prototyping and proof-of-concept stuff). I see people start to write code on day-1. They spend hours or weeks writing code and then go back and rewrite their own code because they found roadblocks or discoveries that lead them down a new path. Some don't go back and rewrite but end up with a design that can't be extended or easily modified as the business needs change...which leads to re-architecting later. Proper code structure/architecture helps make code easier to understand as well as update. I've worked on projects where a single WinForm had over 30K lines of code. Or a repository class will be named at such a high-level that it contains 60-70 functions that pertain to 20-25 different features; instead of having 20-25 different repository classes. Some people strictly follow a canned methodology or architecture instead of tailoring it to meet their needs for the specific project they are working on. Sometimes poor choices are made because someone is trying to adhere to a strict rule when they should have allowed an exception to the rule (documented of course). Understanding "trade-offs" is an essential aspect in software. Also...always keep dependencies in mind. Sometimes classes or groups of classes are tightly bound together...and that's fine and mostly unavoidable. But do try to keep things into relatively isolated groups or units or components. If something needs a major change, you are essentially limiting how far that change can affect the rest of the code base. Another important note: Be open and honest about your code, your vision, and your choices and humble yourself; never belittle somebody. Everybody is on a different path in their practice. I've seen people with a decade of experience, yet they're still at a near-junior level. It turned out that they were at a single job those 10 years and never really had a senior person to learn from. Others were fortunate enough to be working with a team of advanced senior people who shared their skills and openly mentored. Sometimes they just needed to be surrounded with a good team; but then sometimes they had no interest or capacity to improve. It's worth giving them the benefit of the doubt. Even truly senior people have an unending amount to learn (and they often enjoy engaging in deeply geeky discussions). This is a profession that will never be complete; we are always all just perpetually "practicing" it.
Yes I am starting a new project and it really demands hard thinking about how to structure it. I am calling it the research phase of the project. I will be mixing technologies with some unfamiliar techniques too. What do you call your plan docs? Design documentation maybe?
"Some people strictly follow a canned methodology or architecture instead of tailoring it to meet their needs" This is a huge one, I think this is one of the biggest problems in the industry right now.
Essentially: 1. Stop not documenting things. 2. Stop not communicating with your team. 3. Stop not treating the last two things as core parts of a task or you will continue not doing them. Gonna write that on a sticky note.
These are excellent pieces of advice. I have a specialist/senior team member whom I admire, and they follow every single step you've mentioned. Thank you for sharing!
All of you in the comment section and this video have added a lot of value to my knowledge in just 15 minutes. I am a freelance full-stack developer, and as a beginner, I make a lot of mistakes. However, despite being a beginner, I always take responsibility for delivering a better product. This thing will definitly help!
As a Scrum Master, I appreciate your thoughts very much. I especially liked the points about refactoring (I agree with you make it a standard part of your work), collaborating on new patterns, and DOCUMENTATION. I would much rather the team finish what they started than build up future problems for themselves. Technical debt destroys healthy momentum. Thank you for a very thoughtful video.
I love the "As professionals we cannot let that happen" argument. Nothing describes Senior Engineer better than lying and hiding things from "Management". Great advice.
It's not really hiding things from management, unless you like being micromanaged. Just like you wouldn't submit all your draft hand drawn problem solving you used to refactor; it's composite to the process. If they ask, tell them, but it's details they don't need to know about only means slowing things down to explain what they should be entrusting the senior dev they employ to handle on their own.
It's hiding things, plain and simple. This is BAD advice. The better solution is to JUSTIFY the refactoring. Refactoring for the sake of refactoring is usually bad and hard to justify. But if you can justify to your management that this will reduce costs and/or is required to support new required features, that's how you task it in your tracking software.
I don't normally comment, but as a senior manager I say please don't do that. I have to trust you. If I don't you won't be around long. Frankly I don't have the time to micro manage. I rely on my seniors to lead the mid and junior level engineers. I completely understand the impulse to feel ownership of your work. I have done it too. But you don't own the code and it is possible they know about things you don't and are making strategic decisions they have to. So honesty and frank sharing of your concerns are much better advice.
@@ericwill1747 unfortunately there's so much more than just "reduce costs and/or is required to support new required features" and only a senior developer will really feel what those are. For example, junior developers are learning on the job mostly from the code itself, so if you want them to up their game you need to factor out the bad teachers. Also, you're asking a junior developer to put a dollar value on a refactoring effort is stupid. We cant even estimate time, how would a novice estimate value?? That's the whole point: senior developers have a sixth sense for technical direction. Bad code has a "smell" etc. Don't put your refactoring up for discussion with people who have no understanding of these things, because they WILL feel compelled to make a decision about it and like a horse and cart falling off a cliff you will imperil us all!
@@delanym As a lead engineer (which I am), I would not be happy if this sort of work is hidden from me. As you said, a junior engineer cannot yet be trusted to make these types of decisions accurately. And taking longer than I expect them to do it will probably look bad on their review too. I would expect such a junior engineer to come to me or another senior engineer on the team to figure out 1) how much longer the refactoring might take to implement 2) how risky is the change (and how much Test needs to reverify everything) 3) what we expect to actually gain from the refactoring (performance, future maintenance time, easier understanding of code are all perfectly acceptable reasons, not just money). Once we know that, it's up to the lead to decide whether the cost of the refactor is worth it. I would praise a junior engineer that came to me with these suggestions, even if they weren't valid, because they are at least trying to think about what's good for the project.
Debugging Methodology is really important and when I was a Junior engineer that was really my wow factor from the senior engineers. During an incident or an problem to have a senior engineer be able to methodically walk through the problem and code in a confident manner and ask good questions really seperated them from the rest of the Juniors. Even Seniors who just joined our team would be able in a few days be able to debug critical issues and problems much more efficently than I could at the time. I think the paradigm that I've developed for debugging in this regard is just understanding how each system receives its inputs and returns its outputs and being able to articulate that well to others either in written form or in verbal form when walking through the codebase. Then understanding the limitations of each system at a high level and being able to explain their purpose really reduces debugging which Junior engineers don't really have since they have so many new products to learn and understand.
@@MrTridac Using a debugger isn't the same as debugging methodology at all. e.g. on a distributed system where the bug only arises across nodes - good luck making use of a debugger there :) (though you could record memory and then analyse it afterwards, if you need that the logging was likely not up to scratch)
@@Bozebo That's why I prefer tracing. My code usually writes extensive log files when in debug mode. I also constantly change the things that get logged to chase bugs.
In my company, the ones that move fast who get the features implemented (by creating tonnes of tech debt) get the promotions, as they are the ones that are noticed by management. The ones that push back to create better documentation, have peer reviews and plan refactors (to fix all the crappy code) are the unnoticed ones that never get any praise or promotions
I remember spending 6 months writing a very good custom data grid (since for specific reasons we couldn't use Kendo or any other data grid our company approves us to use), then 2 months after, the company approves us to use Kendo again and my 6 months is gone. It really sucked...
Excellent point. You've probably heard it said that most programmers are better at writing code than reading (even good) code. When I started really trying harder to understand code before I would make any changes, I found the job MUCH easier. I was too quick to rewrite my first 5-10 years in.
While reading bad code is essential because you will get a ton of it from less experienced engineers. I think an even better attribute is to be able to read/follow code in languages you aren't familiar with.
100%. One of the things I always do (if I have the control) is to setup formatters and linters that are triggered as part of testing in CI which then automatically surfaces when code deviates from the standards. Individuals can write in whatever style they want but if it doesn't pass the automated tools then it won't even make it to PR. I will say though that I've worked with plenty of other "senior" (cough - title inflation cough) engineers who have disagreed wildly with some of the practices mentioned. Used to be "self documenting code" (that never was) and now it's no documentation at all. Not even useful comments (the number of times that I've flagged comments for looking more like "notes to self"...what about the rest of us, what do we need to know? Overly convoluted code that tends to demonstrate how clever a programmer is. Premature optimization in some places and yet in other places not thinking that a quickly growing dataset can't possibly be loaded into memory in its entirety (I'm literally referring to loading the entire results from a query and then manipulating, potentially making copies, etc.). I really think a couple of huge problems I've seen in this business (at least in Silicon Valley) is the abundance of arrogant, relatively inexperienced programmers (now always called "engineers") who not only have benefitted from title inflation but because of it think they're smarter than those who have more legitimately earned the title through the sheer number of projects that have been worked and with a depth and breadth of expertise.
Some great points here. I'm going to do a future video on how modern society and its obsession with youth culture is destroying the software industry. Stay tuned!
Thank you for the advice. I've written code since I was a kid, but I'm only about a full-year into my first development job. I've always thought I've written good code until my lead constantly revises what I wrote. I'd really like to grow as a developer and show them they made a good choice. I really enjoyed your style of teaching. Definitely subscribed.
On documenting chosen patterns (chapter 3): If you don't know where to start, I recommend the Architecture Decision Record (ADR) format explained by Michael Nygard's "Documenting Architecture Decisions" article. ADRs made it easy for me to document architecture and design decisions and patterns. I think ADRs are a good way to do what the handsome man in the video demands by 'document chosen patterns'.
What you've said here about adopting new standards and slowly rolling those out across the code as you maintain it... It's exactly like what the Netherlands did with their cities. They implemented new street and road design guidelines, and over time as streets needed maintenance those codes were implemented. Now they've got well designed streets with all kinds of safe infrastructure and bike paths, and they didn't need to spend any extra money, it was all part of the maintenance budget.
Very interesting points. It boils down mostly to discipline. The point about refactoring and managers particularly resonated with me. Managers seldom care about enforcing discipline,... I have seen many projects going into a wall because of that. Don't let yourself get eaten away by them. When they always have the final say, it can be better not to give them a chance to speak at all. They don't need to know exactly what you do: they just need to know when each given feature will be ready. Give yourself the time to do it right, because they won't.
i think it is a good practice to measure refactoring time and include checkbox for it on your story. if the manager doesn't like it, the problem is that the manager is an idiot, not with your organization practices :D
Discipline is everything for non-creative work. But when overdone, it may kill creative potential and make work mechanical and people passive agressive.
why would you care? it's their responsibility as long as they are aware of it, but I agree, they don't need to know what you're doing, depends on the company tho
2 роки тому+9
Great video 👌 One thing I'd like to add about refactoring tasks. I used to do as you said, but I found that this is really limited to everyones active memory and therefore difficult to follow through. What I now do instead is - I create relevant refactoring subtasks under a tickets with other sub tasks. This ensures everyone remembers to do it and also communicates clearly to the business stakeholders why is a refractor even necessary. It also helps to distinguish actually necessary refractors from the ones where you just feel like it should be refactored. This of course only applies to notable size refactoring. For small reactors it's just a part of the task.
Ahh you're getting ahead of me :). Yes sir!! On a team where it's safe to make refactoring visible, we do this. But that's to help the dev team keep track of the refactoring progress and make sure it gets done. Not to report it to management! Thanks for leaving this comment, I'll talk about this specifically in the future!
Great info I've become really passionate about documentation, but as a less experienced dev I'm constantly haunted by the idea that "your code should be clear and self explanatory" and although I don't feel that I'm relying on documentation to explain my bad code, I worry others will think that's the case
Most experienced devs will ignore the comments, so make sure your code is good. So long as your code is good, no one will accuse you of using comments as a bandaid.
@@jgnhrwhas that really been your experience? I don't doubt that it has. It's just interesting because in my case, at least in the consulting world, the more senior technologists always use the comments (and documentation) to get as much information about the solution as possible. Different strokes for different folks I guess.
Amen, brother! One thing I noticed: Highly skilled programmers sometimes are sorely lacking in communication skills. They produce insanely complicated code, often not on purpose, while disregarding that they probably won't be the person maintaining it.
My company doesn't let us individually point stories, it's a collective and you can say this user story is 8 points, but if the rest say it is 3-4, it usually becomes a 3 or 4 point story. Then oh look it is more work than they thought, it should have been 7 or 8.
Totally started coming to the same conclusions recently, and this just gave me a bit more confidence to commit more to getting things actually done, much appreciated
As a senior developer I have made it a habit to reject any comment that says "TODO: Bla bla bla" if the comment doesn't reference a concrete work item or user story where the undone work is specified. It comes from being frustrated with opening decades old files with legacy code that has TODO comments that I don't understand the details of and all the people who were in the company when that comment was made have since left. I feel like having a T-shirt printed with a picture of Yoda and the text "Do or don't do. There is no //TODO".
"If you don't have time to do it right the first time, what makes you think you'll have time to redo it." I had that quote on my whiteboard for years.
I remember that quote from one of Robert Martin's books ("Clean Code" i think)
@@GerbenWijnja my quote on the whiteboard would have pre-dated that particular book. I won't claim that I made it up on my own though. Have read quite a few development books and magazines over the years.
At times, producers say we can deliver a product to get funds and then we can refactor, but that mentality sticks and refactor will always be delayed with a similar excuse. On the other hand, usually code can be improved and if we dont set a time limit, things will delay too much not because of lack of perfection, but quite the contrary.
- if you don’t have time to enjoy some coffee this morning, what makes you think you’ll have time to enjoy some later?
- if you don’t have time to fix the roof this monday, what makes you think you’ll have time to fix it this weekend?
- if you don’t have time to finish that game you just bought, what makes you think you’ll ever have time to finish it?
this is one of those deep sounding quotes that sounds smart and deep the first time you read it, but makes no sense the more you think about it.
Sadly the management of projects no longer care about quality. Only getting the product out and letting the user do the testing. Netscape started this back in the 90's and Microsoft put it onto game systems with the first Xbox.
Also, if you're in a code base with irregular formatting and you want to make a clean up of formatting (whitespace and/or braces), be sure to make a commit that only does the reformatting and no code changes.
Formatting changes touch nearly every line of code, and if there are logic changes sprinkled in, it becomes very difficult to find them if 90% of the lines are changed.
GREAT suggestion. 👍
100% this. As someone who reviews a lot of code, there's little I hate more than a 1 line change hidden in 100s of lines of reformatting. Make the review process as easy as possible for the person reviewing your code. If you use a PR based review process, create a commit and PR just for the reformat and make sure that the reviewer knows there are no functional changes. Then with the formatting out of the way, go and make your actual change and PR as normal. Your peers will thank you!
Saw this only last week in a code review - utter genius and instantly became lodged in my brain to use in future.
In the same line of thinking as this, I will often just do a big formatting commit, then PR the thing and get it into the main branch as soon as possible. That way everyone can merge it into their feature branches as soon as possible.
Reformatting can only be done on projects that do not have long lived branches and merges among parallel code paths.
I'm a senior dev and a scrum certified product owner and I can honestly say that many organizations abuse the whole velocity concept to prematurely force developers to "finish" their stories and tasks. They have taken something that developers love (development) and turned it into a sweat shop.
So please, respect your developers and stop pushing your team to its absolute breaking point just to meet some arbitrary velocity.
100% agree! Velocity is a vanity metric (looks good, but doesn't really represent truth). I love that term - coined by Eric Ries of "The Lean Startup" book and method.
You're right, worst case scenario the product become like Cyberpunk 2077
could not agree more... worked for a company that did SAFe Agile, it quickly turned into being all about the numbers.
@@karenj5880 I think you'll enjoy tomorrow's episode ;)
I'm a senior developer too but you don't need to be one nor be scrum certified to know this. You don't need to be a rocket scientist to know this kind of metrics gets abused.
I've work inside a very large manufacturer, and when I present all of these principles--and try to enforce them on new projects from day one--I'm very surprised by the reactions from other team members. This video assured me that I'm not crazy and I've been doing it correctly for decades... Thank You.
oh yeah. thats the real struggle.
Ofc you're better off starting with principles... Changes cost, rework is frustrating. There is, however, the art of presentation, of making a speech, so maybe you could improve on that to receive more support?
Mavericks are great for one-person projects, and that's it.
@@Manofry It might work for the next project, but once you have proposed something and management have made up their mind it would affect their ego giving up on their earlier decision, so they will likely choose to go further down that path regardless of how well you present things now...
@@icoivo5529 Agreed, that happens often and you'd need popular support to change their decision if they're insecure like that.
20+ years of development experience here - I agree with all these points. To reiterate an overarching theme, as a professional developer, do the professional thing and take ownership for your software. Notice the keyword being "software" and not "code" because software is more than just code - it's the documentation, communication, refactoring and timely delivery of that code.
Bollocks. It's all code. But if it makes you feel better you can even pretend to be an "architect".
@@i-am-the-slime Only until someone needs to test it, deploy it, use it, fix it, change it, sell it, integrate with it, support it etc.
Not just take ownership, but code with others in mind, not just yourself. I've seen more problems with coders going their own way than just picking a team standard and configuring it.
I am constantly amazed by developers who do not produce artifacts during development, no code commentary, no Release Notes, no User docs. AS you state 'code' is only part of the software deliverables.
@@i-am-the-slime I was thinking city planner. Why muck about with just one building?
I like the quote “There’s nothing more permanent than a temporary solution” It applies well to the leaving code j finished scenario
"The quick is now, the dirty is forever" is the mantra of my manager.
There’s a lot of selection bias there though. There are uncountable lines of code I’ve written that were 100% throwaway that did, indeed, get thrown away. Being senior means recognizing when you should finish something properly or not.
In Poland in time of communism where people lacked everything we often made such a "innovative" solutions from what was at hand. Here we call such a temporary-permanent fix "prowizorka" from English provisory i guess. Maybe Google pictures can shows some examples for the phrase. Today it competes in meaning with "a crappy replacement" but once was an art of survival & reason for a pride in overcoming headwinds building something from nothing magic.
In politics temporarily taxes also become permanent... Satiating short term needs whatever way - because of lack of accountability that becomes a part corporate culture. What proves how illusory democracies we are living in are. The same as in communism - everybody feels all rights to use the public property as their own for own benefit but do not feel any obligation to maintain it, despite eventually still paying for it personally. Laws of jungle. A company with many bosses has no boss & noone responsible for decisions made there. Hierarchy at least provides a stable face to blame. Lack of time, money, resources or will to build long-term in reality are only excuses for those who doesn't care. Owner cares, renter don't. Drifting is always a sign of a captainless ship. Better to be a servant on a ship with captain & prospects than on a drifting ship without any direction slowly consumed, demounted by whoever likes. Equal rights is such a lie.
I love that quote! How true it really is…
Also true for many other things. Like moving to a new city and looking for an apartment "for a short time before I find something really nice" and then finding yourself living in this barn after 3 years. Same - to do something quickly and hope to change it latter.
Jamie,
This was great advice as usual. I started programming 50 years ago back in 1972 before Structured Programming had been invented in 1973. At the time, it was thought that writing computer code with the fewest lines of code was the mark of a truly gifted programmer. Remember, at the time, many programs were written to be only run one time by the person who wrote the code! This was very much like the Baroque period of music (1600 - 1750) in which Bach lived. So, at the time, programmers were like Baroque composers such as Bach who were commissioned by the King to write a piece of music that was only intended to be played one time at a particular regal function by a single orchestra and then discarded. So there was very little effort devoted to preserving Baroque musical compositions, and that is why we have very little Baroque musical code left for us to enjoy beyond the works of Bach and a few other composers. Only later in the 1970s did I run across "canned" programs that were meant to be run more than once using input data punched on a deck of cards. That's when I learned that "truly gifted" programmers did not write code in the fewest number of lines of code. Truly gifted programmers wrote code that others could understand and work with 10 years later!
Regards,
Steve Johnston
I really enjoyed your comment.
While I haven’t been programming for as long as you have. I’ve found that functional programming, in my limited experience, does usually result in having fewer lines of code and that’s usually a win.
Coming from Elixir as my first impure functional language, they have doctests which will be included as an example in the documentation generated and also fail if the function implementation doesn’t abide by the example input and output written in the documentation.
So as long as each function is kept small, has a doctest written, and then each of those are composed in order to create other functions which do more things, then the code being written in a terse manner shouldn’t affect future readability or maintainability.
The mental overhead of 100 five to ten line long functions is far less than 10 100 line functions.
I always try to keep it to 20 to 30 lines max for a function.
@@jamesgood7894 James,
Functional programming is much like the programming we did from 1975 - 1995. When Java hit in 1995 everybody dropped procedural programming for object-oriented programming and the C++ programmers just laughed at the rest of us. Structured Programming was invented in 1973 but it took a few years to catch on. Using Structured Programming concepts in the 1970s, we wrote "Top-Down" programs that had a mainline that called lots of subroutines. This was a huge leap from the "spaghetti code" written from 1955 - 1975. In 1972, I started writing FORTRAN (Formula Translator) spaghetti code to solve physics problems. These were disposable programs that were much like solving an algebra problem. Once you solved the problem, you threw the code away. We used single-character variables as much as possible so the code looked like: A=B+C, and I only knew what the variables stood for. When we ran out of single-character variables we would resort to two-character variables. We were punching code out on IBM 029 keypunch machines, so you tried to minimize the number of buttons you had to push for each card because once you pushed the wrong button you had to eject the card and start all over. We would write a few sparse lines of code that way and then jump to some other cards with a GOTO. After the GOTO we would start up again with some new cards with unrelated logic in them. This way we could easily jump back and forth in the code to add more processing by simply sticking in some new cards between the old cards. We did most of our troubleshooting by flipping through the card decks. We never actually saw the code in its entirety until we did a compile and you sure don't want to do a compile because it costs a FORTUNE! In the early 1970s, our compiled and linked executables had to fit into 128 KB of memory or less and that also was an incentive to do very terse programming. United Airlines wrote the Apollo reservation system in 1971 using huge amounts of FORTRAN spaghetti code that ran on the IBM TPF (Transaction Processing Facility) operating system that still exists today for high-volume transaction processing, I worked at United Airlines from 1999 - 2003, and one day I found a printout dump of some Apollo FORTRAN spaghetti code that was still in Production! You could barely understand the code and that is why United Airlines was still running it. So pay attention to Jamie's recommendations when you write code because the code just might live longer than you do!
Regards,
Steve Johnston
@@stevejohnston2137 Yeah, Structured programming does sound quite similar to the ideas in functional programming.
There’s also a book called data oriented programming, which really puts emphasis on the benefits of separating the data from the functions which operate on the data.
It just seemed as though the same things can be achieved in FP as in OOP, perhaps not in all cases, but in a majority of them and in a simpler manner.
From reading the book on data oriented programming (it was a while ago and I haven’t finished it yet), the author recommends designing your app data in such a way that it’s normalized (think as if you were designing a SQL DB Schema.
Then from any function in the application, that large app data can have CRUD operations performed easily by accessing a particular subset on the app data via what the author calls the “information path”.
He’s using a dynamic language in his examples, so the information path is just a list of strings which can be used to dig deeper into the app data, which is just a hash/map/object. The author thinks dynamic languages make this an easier process, but there is a formalism in functional programming for being able to handle the same things without much difficulty in a statically typed language. I kotlin has the Arrow library that supports optics, which allow you to access/update/delete within deeply nested data, and there must be other languages which have similar third party libraries which support optics.
All the explanation above is to say, if you’re doing the Structured programming idea of top down design and many sun routines, then the higher level functions will normally be passed the large app data and then when the subroutine functions are called, they can either be dependency injected with the app data as a whole and an optics function necessary to accomplish they’re work, or just have the high level function use the optic function to access whatever subset of data is needed for the lower level subroutines.
I’ve only worked on one small contract gig and have very limited professional experience aside from that as a programmer. However, I think the benefit of the above is that you minimize the amount of parameters of a function and future changes to the data can be facilitated easier as you’re usually only accessing that data in one location.
I’ve heard of the punch card system, but haven’t seen the process which programmers have to go through when doing their work; it does sound quite tedious and I imagine that the need to minimize compilation the number of compilations made due to how expensive it was required a planning and design process that is much more elaborate than many of the places which I might be employed at my current level (looking at startups).
@@jamesgood7894 James,
Thanks for your thoughts on Functional Programming. It brought back many fond memories because all the procedural programmers back in the 1990s made the same case for keeping data separate from function when Object-Oriented Programming came along. You will see this many times in your IT career. We all keep going around in technical circles. That is why Jamie's Healthy Software Developer channel is so important because it deals with the people-problems in IT and those never seem to change. I saw the same people-problems in the 1980s, and when I talked to the "old-timers" who did IT back in the 1950s they gave me lots of the same advice that Jamie is giving to you today.
For example, in the 1970s we did Agile development because software was usually written by a single person talking to a single business person. Executables had to be less than 128 KB in size so a batch system consisted of many little 128 KB programs strung together with JCL. The little programs read and wrote sequential files on tape. A 128 KB program might read a Master tape and an Update tape and write out a new Master tape that was then passed to another 128 KB program as input. That program would read the new Master tape and do some more processing to maybe flag accounts that were past due. It would then output a new tape with the names, addresses and account information on past due accounts. This kept going until you finally got to the last 128 KB program that printed out past due letters to customers. This was all done in a very incremental prototyping manner without any formal design documents. Then in the 1980s, we were able to write programs that were many megabytes in size and this began to be done by teams of developers. That's when Waterfall development took over with lots of formal design documents created before any coding began. The Waterfall approach held firm for about 20 years until Agile came along again. So it was Agile -> Waterfall -> Agile. I won't go into the details but we also saw Cloud Computing -> Distributed Computing -> Cloud Computing over the past 40 years too. The important point is that IT technology will constantly change throughout your IT career, but the IT people-problems that Jamie discusses just seem to go on and on!
Regards,
Steve Johnston
Mr. Johnston, thank you so much for sharing this! Not only it was fascinating but also insightful! I'm just a neophyte, but I'll take this one with me: "Truly gifted programmers write code that others can understand and work with 10 years later!". Adding it to my Notion notes so I'll always remember! Thanks again!
I think some of points that distinguish a senior programmers for me :
- They know WHY: when you ask a senior why this was done, they will usually have a logical answer, even if you don't agree with it, but their point will be consistent and reasonable, and usually will offer another point of view that wasn't obvious.
Juniors and "Pseudo seniors" will usually give excuses, can't provide a consistent answer, or pretty much rely on their authority to push their view.
- They have insight: Good seniors can make use of their experiences to predict the different outcomes of different decisions, in a way, they can make mental simulation, and so, they can save their team lots of time and effort by guiding them to avoid future problems, or at least set the project in a way flexible enough to keep going without hitting a deadend.
- They are good at handling and understanding business-side: wither it is based on trust or good arguments, good seniors usually know how to deliver their points to product-owners, product-managers, or business users. They may predict the business side concerns before feedbacks, or
- They are good at making trade-offs: this is based on the last points, with enough experience insight and negotiation skills, good seniors and tech-leads can make flexible trade-offs to offer the business as much value as possible.
- They are NOT perfectionists: Good seniors that "Good enough" is always better than "Expensive Perfection"
Absolutely EXCELLENT points. I did a video called "What really gets software developers promoted?" that is very inline with your observations.
If you haven't watched it already, you can find it here: ua-cam.com/video/P3bRQVw6Mrw/v-deo.html
A recommended rule of commenting is that explicit comments should answer the "why" questions and everything else about the code should be built into the code's identifiers (so the code is self-documenting).
@@Raging.Geekazoid I used to feel the same way. In my experience over the past 10 years, this is a nice idea but unrealistic in reality. We've been sold an identifier is enough. I believe we're overly confident in the simplicity of our code. Most code requires at least some comments to help someone other than the author understand it quickly, regardless of how much thought we put into naming. As always, this is just my opinion.
@@HealthyDev Ha ha. In one project, I actually broke down and drew ASCII diagrams of tree structures in a separate text file because they were too big for the source file. So I can't even follow the rule myself. 🤣
I try to though. 🙂
@@HealthyDev I try to usually comment only the "why" aspect, but I do agree that some code does sometime require the "what it does" explanation. It should be used rarely since the goal should be to write more self explanatory code, but we all have different mental models in our head and different levels of experience so that isn't always easy.
Of course, commenting "this checks if this is true" above a variable is useless or annotating every few lines of code, but there are cases where few lines of comments sprinkled throughout the implementation is really beneficial.
“Programs must be written for people to read, and only incidentally for machines to execute.” - Harold Abelson, Structure and Interpretation of Computer Programs
that is why we have so many bugs and low performance.
@@brunonovais8801 ...due to the violation of this principle
@@brunonovais8801 Can you elaborate on that (a)causation?
@@m4dalex478 Oh my bad, I though he meant writing code to be readable is why we have bugs and poor performance
I've been a freelance graphic designer for almost a decade. SO much of this is exactly on point. Levels of communication, consistency, and clarity are what really separate the individuals who are a joy to work with to those who may be talented, but I would not want to work with again.
Don't be distracted by language syntax and coding patterns - habits are what makes a senior programmer! Here are some of the best one's I've learned. What are yours?
►► Know your options! Access my FREE data hub for the top 25 software industry roles, TechRolepedia → jaymeedwards.com/access-techrolepedia/
Great content - What are the intermission music bits? Something we can get hold of?
@@TheCodeTinkerer hey thanks. The music I've been adding to videos since returning from my hiatus are parts from songs I've written over the years. I hope to be putting out some music over the next year or so.
@@TheCodeTinkerer hrmm. Not sure. I prefer to get it out done otherwise I lose motivation once I've shared it half done lol.
coding pattern is a must for senior . syntax kinda similiar any language .habit nahhh. code clean . bad ! interface bad ! mvp first .
these transistions are sublime
I’m a software development manager and former front-end web developer since 2003, great video and it’s interesting to see someone give their perspective on what it means to be a senior.
I’ve been a part of many projects, both brand new development and inherited code bases at several different companies in my career. What I look for when hiring senior developers is a sense that they have some wisdom and experience in what they do, regardless of the language they code in, you can see from interviewing them that they’ve encountered many different development scenarios in their career and they think deeply about what they do.
They aren’t too hard-headed, or proud, or set in their ways that they think they have learned everything they need to know, and everyone needs to do things their way because they know best. Humility is vitally important for cultural reasons in a company and also for the success of projects to be able to see obvious pitfalls and roadblocks during development.
Over-engineering can be the death of new projects and features. I want my developers thinking about solving the problem as simply as possible from the get-go and only introducing further complexity when it is required. I’ve even done it myself where I’ve tried to implement a new tech stack that I wanted to use, only to get into it and find out it’s adding way too much time and complexity. Usually because the documentation and best practices says that I require a whole lot of scaffolding for my application. This is bad for business. Take best practices into context but still try to solve simple problems with simple solutions.
Dependencies create complexity. The more dependency you introduce in a code base, the more chances you will create bugs and add fragility to the project. If you reduce dependencies you will likely reduce the bugs in your software.
Also, code so that others can easily understand it and debug it. Even if that means a few extra lines of code. You shouldn’t need to write novels about how your code works, it should be readable and easily understood even for a Junior developer. When code is over-abstracted it can be difficult to track down the root cause of bugs. Personally I’d rather read code than documentation about the code. Abstraction also adds complexity.
Anyways these are just some of the things I’ve learned so far in my career, and it seems this type of knowledge is a bit scarce these days (I’m trying to hire right now haha)
All the best to everyone out there and happy coding! May your days be bug-free with happy customers :)
I have been programming over 45 years. In too many projects if have seen a rush to produce visible surface results without first building and testing out the functional foundation. This is because management typically has its focus on visible features and doesn't appreciate the art of well structured code. Each sprint should include development of foundation function in anticipation of rolling out features in future sprints. This goes along with your recommendation to bury the refactoring effort so that management doesn't sabotage it.
Couldn't agree more. I learned this hard way during my first role as a senior dev. I was tasked with building new features on top of a poorly written legacy code base. I was turned down every time I mentioned incorporating some extra time for refactor. The company wanted results, and they wanted them fast, and tried to explain to them that the only way to deliver the results they expected was to refactor the project to be more modular and extensible (which it was anything but). So I just said "screw it" and started implementing incremental refactor where I could, without telling a soul. Lo and behold, over time I finally got the system stable enough that we were able to roll out new features at a reasonable pace. The main issue was a severe lack of orthogonality in the code. Changing one small piece of functionality in one component basically meant having to change at least a dozen other components to keep up, and it made everyone's job 10x more difficult than it needed to be. Being an integration engineer can be quite the challenge, but there are ways to handle it.
I have been doing this for a while, its frustrating to be honest. The most annoying thing is when a manager asks what the customer value is of a refactor because its not a feature, but makes a surprised pickachu face if a feature is extremely hard to implement because of coupled foundations that should have been refactored a long time ago
@@guidobit These type of managers are hard to debate with.
IMHO it's partially, because SCRUM doesn't include a mandatory architecture phase. The success and viability of a piece of software depends largely on it's architecture IMHO. And managers are kids. If it isn't visible no work has been done. If it isn't a large piece of code you haven't worked hard enough (that's why Java was invented). So I tend to write a lot of UI stuff first with mockup functionality, so they have the impression I'm actually working pretty quickly and leave me alone.
We already did that in the eighties by making the menu first. Sure, nothing happened when you clicked - but it didn't change during the entire development phase. The sole difference was that at the end of the project *something* happened when you selected a choice.
Yup. Because they don't care. They just want to get salary bill.
My second comment on this great video. I met a guy that was working at my old employer, but didn't know it. After being introduced he asked me if I used to work there. I said yes and he went on about seeing my name every day in all of my 20 year old code. Made me feel really good about my work.
That's a great story. I too look at other's old code and can sometimes tell if they've made that line of code before or after lunch.
As a project manager I cringe about "don't make documentation and refactoring additional tickets because they might be axxed", not because it is wrong, but because I remember how often I fought for these tickets because I knew they would work for me in the long run. (and often got defeated anyway, so you are right)
Isn't it a breach in transparency, that is one of the scrum values?
@@МаксимФедосов-з6е Speaking of transparency, where are the kanban for the execs?
The problem with this is that developers, especially freelance or contract developers, rarely have any understanding of the commercial side of the business.
So, you might think it's being professional to hide this activity and protect management, blissfully unaware they're making decisions about the health of the company based on the faulty information you're providing.
@@RylanStorm In my experience, execs actively ignore "technical" information, whereas devs are paid to figure things out.
Often devs are even paid to figure out how to build features the execs already sold because they were feasible in theory.
Is throwing the executives out the window part of scrum? It should be. @@МаксимФедосов-з6е
I really love that you wrote the summary text in the description. I've read the essential parts much quicker than it would take me to watch the video. You are a senior UA-camr for me, many thanks!
I'm really glad you started making videos again. You teach things we can't really learn from anywhere else.
Agree!! I am sending his videos to developers just starting their career
things we can't say out loud! 😂
I think a big one you missed is to build modular code and dependency minimization. As you get more senior in your programming career and you see both technology and requirements change on at an increasing rate you will really start to value being able to change a piece of a complex software without bringing the whole thing down. This requires building in isolation into your code from the very start since its often an architectural choice, not an algorithmic one.
About "unfinished work" however, I slightly disagree. I think more accurate is to say senior programmers get better at knowing where to cut off development. There are just so many things you can do to software post-"it works" phase, like better validation, security, instrumentation, optimization, usability, testability, accessibility... you can easily turn any function into a bottomless pit of development hell if your want. As you get senior, you get better at knowing how much of "finishing touches" does your piece of code/software really needs for the next 5/10 years.
"I think a big one you missed is to build modular code and dependency minimization" - that does make sense, but it can also lead to overengineering and trying to be too smart too early in many cases. I don't know in which field of programming you are, but I work in frontend development and in my (highly subjective) experience from projects I've worked on, there is rarely a need to swap out something super big so that super modular dependency injection design (or whatever) that you might have done is wasted 99% of the time. You'll be grateful that 1% of the time, but bunch of the time you'll potentially be trying to be too modular without any benefit. There definitely needs to be modularity and some abstraction and re-usability in lot of parts, but not everything can or should be super modular.
"I think more accurate is to say senior programmers get better at knowing where to cut off development" - Totally agree, I think this one is a big defining characteristic between senior devs and devs that are junior/mid. Senior devs know when to skip something or make a compromise that won't hurt a particular feature or whatever is being developed. They have the authority and confidence to make compromises where needed, but also push in areas where compromises shouldn't be made.
Subroutines upon subroutines
Dependency minimisation sounds like 'one big class doing a lot of things'
@@tomaszk9210 Not at all.
There are two main categories of dependency: internal (the source code with itself) and external (libraries that are used).
A large class increases the probability people will start making references to internal variables and methods all over the place, and you end up with spaghetti code that is so interdependent you rather throw it out than refactor it. Dependency injection became popular exactly because of this, it forces each internal "service" to define a clear API and keep its dirty paws off any of your "main" code. Creating code layers and breaking up circular references between two layers is also another popular strategy to minimize dependency.
External dependencies are the other category. But this one is easier to understand. You rather call 1 external library that you use 10 methods from than calling 10 libraries that you call 1 method each. At a certain point there is even a case to be made to reinvent the wheel rather than pull a huge external API just to get 1 tiny functionality from it. Common sense applies here, but its all about weighting portability, API surface and weight (especially in web dev), sub-library dependencies, and how complex and error prone is exactly the functionality you want (ex, in security you really don't want a DIY strategy).
About "unfinished work": I completely agree, it's a creative process therefore we could rewrite again and again every month the same code differently if we wanted to. Even the documentation, sometimes it's just a plain english/language duplicated code rather than just a document explaining the whole idea.
Also, a senior with experience in the same company should know when it's worth spending time on tiny parts.
As someone who does a bit of Dev and Ops, I sincerely believe your comments about refactoring are very true for the Ops world as well. When there is an opportunity to automate a manual process and it keeps getting pushed off by management in favor of the latest feature, the only way to get it done is to simply do it.
Getting that type of improvement work done makes me more excited to go to work, and makes my job and my team's jobs easier.
Yeah, I also believe the management of devOps processes should be within the development team's management, not the business management's management. The one should never "bother" the other. If dev resources don't allow for that, i.e. automation efforts slow down normal progress of a software project, then the organization has a basic issue of manpower that needs resolution.
Yes, totally true. If you realize you have time to make a relatively safe improvement, just do it. Going for permission to do every little thing just wastes everyones time and just shows you cannot make decisions on your own. Of course don't go willy nilly just changing everything, but doing improvements when you know you can and have the resources is good.
You try to stick to standards and patterns and principles but the rest of the team does whatever they want... then later down the line they say we have to re write everything and they rewrite everything in another framework but still dont stick to any architecture or standards 🤣🤣🤣
@@BillClinton228 Ya I hear that as well. It's hard to stick to standards and do things the right way. It's easier and faster to cut corners to get the job done and make the customer happy. The problem is, that the next project/task/ask is going to be that much harder to deal with, multiplied by the number of other people on the team. And hopefully nobody on the team left the project and didn't document properly.
you need to speak to your TL its their job to get TECH DEBT allocation
Great video! I would add that truly senior engineers not only enforce testing standards, but they also enforce standards for logging. This includes defining patterns for how logs are written, and standardizing what types of logs are used in different scenarios.
First point about not doing that extra cleanup at the end, if you push it off most of the time, most orgs will blame you later for creating tech debt even though they discouraged you to do the thing up-front 😂 always clean.
I've been fortunate enough that almost every project I've been on has been managed by somebody who used to be a developer so putting jira issues in for things like refactoring and documentation and other things we know we need has never been a problem. If, however, your manager hasn't worked in the trenches I can definitely see doing the work without creating a bunch of jira issues.
To me reviewing pull requests properly is one sign of a senior developer. I've seen so many PR's where other developers just approve the changes without really properly reviewing and testing the code, whilst I do and end up finding lots of issues (readability, lack of comments, not following coding standards, bugs, etc...). This is especially important when less experienced developers try to get some changes into the development branch. We as seniors are gatekeepers who must make sure that bad code doesn't get in to development, and if we are lazy and just write "LGTM" then surely the quality of the code will decrease over time.
I agree and other developers really appreciate it when you provide valuable feedback on their code. At least the good developers do. I do think it's important when you provide feedback on a pull request that you do it respectfully and constructively.
Lol Gatekeepers... some of the worst I've seen were written by seniors. Many young developers are impressionable, older developers are already set in their ways of writing alien Cypher as code. Lol
@@igboman2860 In my experience most senior developers are actually not senior at all. While most people who are given the job of being gatekeepers are unfortunately unqualified - it does help to have a qualified person help level up the skill and quality of the team. Unfortunately with modern hiring practices that's getting harder and harder since we keep promoting young and inexperienced engineers and the ones who finally really do learn the ropes leave because they're tired of the politics. We can do better as an industry!
This is one of the biggest gripes I have at my current company. Most people will get a notification about a PR and it's approved with no feedback within a couple of minutes. At least a couple of times a week I have to call a halt on a PR that's already been approved and potentially merged because of some glaringly obvious flaw.
@@Corrup7ioN yeah that's quality theatre. The appearance of quality but just a waste of time. I've been on a project where we had to stop doing PRs because they were giving us a false sense of security and not really adding value. If people don't really follow through it's just process overhead.
I'm not even close to being a senior dev, but I found all these points super inspiring to take on. Very nice guitar interludes as well! I had started the video in another tab and was just listening to the audio and thought "ah, nice music" but didn't realise until I switched back at the end, it's actually you playing...! Totally dropped you a follow!
Thanks! My oldest son is named Leo. ❤️
I think putting together good commits is an often overlooked skill that can make code review 10x easier as well as being something that can be referred back to when getting into a codebase for the first time (or indeed the 10th time). Making sure that commits are granular enough to be digestable as well as conveying intent properly rather than just a list of what files are changed and a wordy replication of the diff.
I've heard this a lot in my career, but I cannot relate to it. When I'm looking at a pr, I'm only interested in viewing the change as a whole. I don't care about the sequence of events in that developer's personal process of coding. I just want to analyze the code quality, which is unrelated to commit history. So I almost never find it helpful to look at individual commits in a pr. I look for usages to see why something was added. I think the pr description is the place to explain any justifications for arbitrary implementation choices.
@@megamaser different strokes for different folks i guess, unfortunately for the team i'm in that approach doesn't work as we are responsible for 20-30 microservices with disparate codebases. When your familiar with a codebase because you are in it a lot then i completely agree, dividing the pr into commits doesn't provide much benefit as you already know how the application fita together and what files/functionality needs touching to add featureX. and while i cant speak for anyone else, my brain won't hold 20 odd codebases in my head so breaking it down into commits (especially if logically structured) allows me to cut down on the 'refamiliarisation' time rather than starting at
int main(int argc, char* argv[])
and working through the main flow each time till i figure out the needful. Its also courteous to other developers who may not have worked on the codebase in a while.
those who find it useful find it very useful
those who dont havent lost anything due to having granular commits as there is always a method to view the feature as a whole.
Agree, it's the first thing I look for in the project is the source control history. I take pride in writing detailed and useful commits because I understand how important they are not only for you but for your team.
One more thing to add to the list: always try to really well-and-trully understand what problem you are trying to solve, how your language/frameworks/libraries really work, what is _really_ going on
Don't code by convenience, as well.
If I'm using a library, I just need to know a bit about its internals, and then just trust the APIs, right? The whole point of using a library is code-reuse, plus the abstractions it provides. If I start understanding the library 'fully', won't that be needless time-sink?
@@balu.92 About the libraries: I think it's more about knowing what the library can do and knowing what it can't. So getting familiar with the documentation and knowing more than just the 10% of the features listed on the "getting started" section of the library's documentation.
Example:
I was working on a project where a certain library was introduced by an external team. It was a very big and powerful library, which offered much more than what we needed, adding quite a bit of complexity. That's ok, but some of the functionality that the lib offered, which we could actually make use of, was then again not used but rather implemented by the external team themselves.
That to me was a case of "There is a lib which looks like it could solve our problems, but we couldn't be bothered to get really familiar with it".
@@HorstKirkPageKian Ah, yes, I agree. Thanks for elaborating! Appreciated!!
Development is also explorative work so you never truly know the problem-solution space until you implement it and then refactor it and then you find ideas how to improve it... Only after many iterations you truly grasp the problem and solutions and rarely you know it before you even start to write the code.
You know you're a senor programmer when you are a Spanish man who writes code
🤣🤣
JAJAJAJAJAJA
Señor
That was hilarious 😂
I look at the code with fresh eyes every day. I am a senile programmer.
I'm a mid-level engineer at this point in my career, and I picked up a lot of these habits early on, purely out of annoyance at the engineers' code I had to work on who used niche, complicated, hard to work on, and mostly undocumented structures and patterns. I think a lot of programmers fresh out of college will go out of their way to use weird quirky methods that will impress a FAANG interviewer like unneeded lambda functions, overly complex ternary operator statements, etc, without thinking about how they're gonna read this same code a month later, let alone somebody else reading the code and trying to add to it. Now I'm gonna be in charge on a brand new repo (that isn't only me contributing to it) for the first time, and I'm hoping to get all this stuff right lol. Thanks for the great video.
When you, who wrote the code, can't understand your own code a month + later without spending a stupid amount of time on it, you are doing it wrong and "They" are also to blame.
*Junior programmer:* _Uses fad parts of the language because they can._
*Senior programmer:* _Uses specific parts of the language because they need too._
I worked at a company where variable names were written in English, in Portuguese and even in both languages. Also, there was no code style, so everyone used whitespaces differently
I warned my boss about it, and a bunch of other problems, then I got fired. I'm happy seeing how you value code standards...
I had to ban pluralized variable names on my team because the english, portuguese, and spanish speakers all used different pluralizations and ALL the plurals confuse the crap out of the 2 chinese speakers we had on the team. Language can create some real headaches.
@@ShotgunAFlyboy the thing is, we are all Brazilians
Bet you were glad when they fired you. Less worried on the long run
Hey nice guitar skills!
I have two extra habits:
1. Reason the code in the smallest increment that adds value.
2. Fix the past before continuing into the future.
Being proactive rather than reactive is also something I see in response to senior development. Thinking ahead, asking the right questions, coming up with a plan rather than just diving head-in and fall into the trap of following the task step-by-step like a robot.
It helps keep tech debt to a minimum, speeds up the overall process as you might not have to go back and forth 2-3 times, and it also tells management that you actually have some deeper understanding as to what is going on in the business aspect.
Establish a good communication flow with management. It will also help when more junior developers come to you for guidance, because you now have the extra insight, aside from just what you know in terms of code, patterns etc. You'll also have the "why" is this feature necessary, "why" is the user flow the way it is etc. etc.
Taking reins when necessary. Stepping up to take directional leads when needed, being able to coach the team, being able to brainstorm or at least present options or solutions to problems you discover either in the code base and/or otherwise, is also something that makes you stand out as senior.
Owning a code base. Having a specific portion of the project that you specialize in, something people come to you for advice in is also a good indicator for seniority.
Senior devs are so much more than just the code they write.
Also, the time it takes you to do that last 15% right after doing the 85% is much less than if you were to come back to it weeks/months later.
You're assuming that you know what the 100% actually is, which is rarely the case. Getting most of the way there is often "good enough", at least from a business feature perspective, and pushing past 80% is usually wasted effort. People realize they didn't want that after all, and want something slightly different instead.
I'm talking about user facing features, and not internal infrastructure. If you cut corners internally you're going to have a bad time.
User facing features are built on the internal infrastructure.
You really should make a great guess and do the ~100% even if the last 15% are a bit off as they take a very short time to do so.
Eventually those 15% are going to add up and not many developers would want to complete an almost done feature vs fixing minor bugs or doing small alterations, it would also result in an unpolished product.
But then again, sometimes there are more pressing features and the 80% should be enough. In most cases, I don't think that's the actual case.
Thank you very much for your new video!
#1 is just the exact reason I abruptly left my last position being burned out and down to nothing. I was porting some old code and because I'm dumb and hate reading spaghetti over and over - I chose to attempt to do it the right, SOLID way with levels of abstractions and all that, but occasionally faking, stubbing and throwing some eye-candies for leads/managers asking to "stop fancy-coding and just do it whatever, so it just works" because a schedule of biannual product releases.
As the time went the chasm between my private progress with unravelling an old ever growing 'big lump of pasta' code and the one I gave impression of grew wider. And eventually I understood that it will never converge and now its probably too late to ask for help (task underestimates, everyone) and then something just died inside of me and I resigned.
I'm somewhat proud of what I was able to achieve in compartmentalizing pasta pieces and some interesting things I managed to do, but I'm afraid most of it might just go to waste :(
But I am being more and more convinced that writing code in such way that if you read it aloud and it would sound like a plain English spec text - it's is the sexiest thing for me, honestly.
"I am being more and more convinced that writing code in such way that if you read it aloud and it would sound like a plain English spec text - it's is the sexiest thing for me, honestly."
Gherkin and ruby!
I have started to follow your channel from few months back. Your videos does reflect day to day shenanigans in life of a software developer. It really helped me to see the bigger picture of corporates from a bird eye view. Thank you for your efforts and appreciate your content. 😊
It's interesting how the main take away here is more to do with organisation and communication rather than actual code. Being professional means taking other people into consideration, listening, and patience. Great advice!
Yes! Glad you enjoyed it.
This is really solid stuff. The only thing I'd add is to practice having the mindset like the following: Bugs don't exist in code that doesn't exist. Nobody spends time maintaining code that didn't get written, so unless you absolutely have to do something, don't do it. A lot of developers suffer from the "newer way of doing it" mindset where they change things for the sake of change, or because it's new and gee whiz or they introduce a more complex way of doing something when there's already an existing tried and true pattern that is much simpler and easier to maintain. Just don't. Unless you have a really good reason for doing so and it's been vetted with the rest of the team.
I say this because all too often (myself included) many developers consider it a badge of honor to have a big ole' fat stack of code that they wrote with a bunch of gee-whiz stuff when they could have easily implemented the same feature/functionality with a much simpler tried and true pattern that is easier to maintain and less bug prone. I can't tell you how many teams I've been on where I look at the actual end user functionality and the amount of code in the codebase and come away going "that's an awful lot of code for what it's actually doing", then get into the code and find myself constantly going "Why is this being done this way? I can't see any good reason for a lot of this code to even be here, because now there's a bunch of code to maintain that isn't actually doing anything towards the end goal, or is doing it, but can be done in a significantly simpler fashion using less code that is easier to read, understand, and maintain". It's like a sickness many of us have.
Yes there is too much Yagni - "You aint gona need it" in so many object oriented projects...
@@tongobong1 Exactly. This goes back to don't do it unless you absolutely have to.
I thought the whole idea of engineering was to make things easier.
My coding practice has been all about that - if I can find a quicker way to make some process happen, then I'll code it. If my code isn't efficient, then I'll refactor it (usually because first pass at a new concept isn't the best way). I learned in the pre-OOP days, where everything was essentially scads of scripts. Once I learned OOP, I was able to take some of my older code (that was still in use) and make it do more toward what it was intended for, with less code.
Still, if it ain't broke, don't fix it. And when requirements change, make it better.
@@l00k4tstuff you should always refactor your code to make it clean and you do it not for efficiency but for readability so next time you or some other programmer will have to change you will understand it faster and you will make the change faster.
@@tongobong1 Yagni is so important 🙂 and sometimes a bit of Wet is also not wrong ✌️
Been watching your videos on and off for a little while now; but as a junior developer who's less than one year in my career, this is really helpful. In a way, it's also validated some thoughts I was having on how I should develop my projects. Thanks again for the tips!
Great, love it. #5 never expose refactoring, I know Martin Fowler in his book "Refactoring" advises that we don't need to ask for permission to refactor. It's part of the job. You justify refactorings by claiming they are necessary as an indirect part of some other user story or bug fix.
But what if you want to refactor and it isn't tied to some specific user story or bug. Now that can get tricky, because in most organizations you need a branch and a PR to make a change, and that requires you to reference the ticket you are addressing with the PR. And you're right, often times your manager isn't going to approve it, and that means technical debt is gonna keep building up in the project and that sucks.
My manager was a stickler for vertically sliced user stories and the INVEST criteria. So I got good at writing them and came up with some clever verbiage to justify work at the user-visible level. If I was really stuck, I might write something like: "As a user, I can enjoy the benefits of a more symmetrically streamlined database schema, so that I can receive higher quality software updates faster." Usually I didn't need to resort to that, I could write it as a more direct user benefit, but dang it all, I kept trying. The one thing I finally got praised for there was writing good user stories.
It sounds like you're really good at writing user stories. And in an environment where the value of a story being "a more symmetrically streamlined database schema" is understood by the management, that's awesome! In other situations, the cost of implementing features for a business includes paying back technical debt. It's just built in and never helps to expose to people who aren't qualified to understand the implications of foregoing required refactoring. Notice I said "required refactoring". I think the reason some managers try to stick their nose into refactoring where it doesn't belong, is they've been burned by prior unnecessary refactoring. I understand their pain. But it's a mistake to expect us to surface everything we do in the context of a user story just because some folks have been burned in the past. My two cents as usual!
I usually put this kind of task into separate tech debt and try to map which tech debt can be mapped to what feature we want to plan in the near future (at most 3 months). I also tried to put the JIRA ticket on each code that we should refactor so instead of TODO REFACTOR THIS BIG CODE just put DEBT-1919 so if somebody sees that and working in the current feature and the ticket is waiting to be done, they can pick it up if they think they also want to refactor.
Yes, the code should be self explanatory 😂that part just made me laugh, whoever said that has never designed or implemented any complex production software. On Incremental refactoring, dying so hard for refactoring for long, I am going to try that and see if it can pass code reviews, great job this episode!
Thanks!
Really like the tip about taking full responsibility for refactoring and doing it incrementally as a team. Something always bugs me when another person says "let's take one or two weeks to refactor this part". This gave me inspiration to handling that situation.
As an electrician, I'm always doing my work with the knowledge that someone else later on will come across it and will judge it. And even though there's no real accountability to me personally, I still like the peace of mind & feeling of a job well done, and the knowledge that whoever has to maintain it behind me won't be cursing the whole time.
Another parallel I could draw from something you said previously, was being pressured into doing work you know is not right. If I were to have an employer (electrical company) try to pressure me into doing work that was unsafe or against code, I would instantly lose all respect for them and start looking for work elsewhere if they held fast. If it was an employer who was unaware because it wasn't their field--like a general contractor--I'd explain it to them that it can't be done that way. At least I'd always have the electrical code to fall back on and an electrical inspector to back me up, which isn't really an option for programming.
I think that's just the point the OP was getting at and it relates to any professional tradesman, craftsmanship and following high quality standards. Everything should be done perfectly whenever possible and when not, it should at least be very unlikely to introduce hazards or difficulties and a plan must be developed to remove the obstacle to perfection as soon as it's practical.
As a former military aircraft electronics technician I actually left a VA "preferred" coding boot camp shortly after the CEO described the software industry as in such dire need for developers that, "you just have to suck the least." That mentality manifested itself a few weeks later in the boot camp. College was enough of a fool's errand for me and I wasn't looking for the same experience on steroids.
I'm still interested in coding, but I sense there's a major down grade in craftsmanship going from aerospace to "tech'" (that term is a misnomer anyhow, because software is hardly the entirety of technology--thank God!). I guess when your product only figuratively crashes, and no injury or deaths are likely as a result, the "time to market" principle can be front and center. I know I know, but what about medical equipment? If you leverage the speed and convenience of software, great! If you make your clinic unable to operate in the absence of software, which fails much more frequently than hardwired electronics, with patients' welfare in the balance, you have no business running a medical center.
Microsoft hardly had a better OS than anyone else, they just shoved their crap down the world's throats so quickly, everyone who is not a computer scientist has to use Windows to run a business or believes that they do. People ran businesses with carrier pigeons and abacuses, long before Ben Franklin got out their in a lighting storm with a kite, so let's not overrate "tech" as a necessity. Tech's purpose is to generate profit. If it did not do so, no one would be employed in the field.
Yes! Avoid getting the reputation of being from the "Blue Spark" school of electricianship.
Just started my first job in tech as an SDE intern, and I am learning that there is a lot more to it than just coding and making things work. This is a great video, Thank you!
Focus on becoming an amazing programmer first and don't get dragged in by the 'water cooler talk' in the first few years of your career. I've seen so many juniors stagnate because of this habit. Also, there is loads of documentation and learning material just in open source projects. Good luck with your career and have fun!
At first I was skeptical because of the title. But I agree with most if not all of what you said here. It's tough to find something that actually explains everything beside the code itself, so it's no wonder why there's a lot of developers who don't know about these things without 10 years of experience. This is a valuable resource for those who wish to become better collaborators in a team.
The approach for clean, readable, maintainable code also applies to any related project documentation, whether that's high level designs, low level code specs, test plans etc.
The mantra I have is... don't write the (what ever the deliverable is) for you, write it for the next person.
Never tell management what they really do not actually need to know.
A lot of it boils down to, senior developers have discipline and instill that discipline in their team. This could go for just about any profession. A true expert has discipline.
As a complete novice I enjoyed the top level discussion. It applies in a lot of other industries as well. Thanks.
You could make an entire video series demonstrating each of these points in detail, such as how to document code and document design patterns.
I will definitely expand on these in the future! I have a google keep note with over potential 200 video topics. It keeps growing all the time...
A couple of my favorite senior programmer proverbs:
• keep it super simple. the easier your code is to read, the more overlay between your code and other languages, the better.
• reduce function points. that is: 1 boolean clause is better than 2. equals is better than not-equals. 1 paragraph is better than 2. 1 parameter is better than 2. etc...
• please avoid fanciness. again. i've coded in some 30+ languages by now. the world changes. it's best NOT to leverage every single corner of the feature set.
• comments and doc-strings, please.
• understand when to stop abstracting. if something can be decided by a single `if` expression, it may be too early to create another child class.
• and it's not as relevant as it once was, but "eat your own dog food" - that is, be your own best customer. learn to automate aspects of your own job. when you can do that, reliably, you can do more; which is what computers are for, after all.
I just started my journey to become a software developer at the age of 44. Every tip or habit i can implement into my work, i am truly thankful for. Thanks for sharing this with us.
Any team project, programming or not, where you're discussing things and making decisions, it's really important to document your intentions with your chosen action. Then also document why the choice was made, what else was considered and why it was rejected, and ultimately what the pros and cons are for the choice you made. Your decision might ultimately be wrong, but it helps get people to speed very quickly, yourself included months or years later when you come back to revisit the results of a decision and can't remember the meeting. If you can see not just what was decided, but why, and what you were hoping to accomplish, that's useful data points when you come back and have to change things later. It also helps when you think you've got a new idea for a change, but the implications were already worked out and your new idea is actually a rejected old idea, maybe rejected for good reason. This all comes down to really good documentation practices, but many people make the mistake of only documenting what was decided with none of the associated reasoning and intentions behind it.
It's the difference between documenting i++; // increment the i variable" and sessionCount++; // update the number of active sessions
They're the same code, just the second one lets you know why they're doing it
I hear a lot from 'senior' programmers saying "I don't need to write documentation, I write self-documenting code!" What they really mean is that they believe their code is easy to read, and if they are good, it's probably true. However, documentation, especially the WHY something is done is incredibly valuable especially down the road when you haven't looked at that code in 6 months, 1 year, 6 years, etc.
Just recently found your channel and I've been enjoying your videos. Great work!
Welcome to the channel! You might enjoy this episode about self-documenting code:
ua-cam.com/video/1NEa-OcsTow/v-deo.html
How many times have I worked on something and thought "who wrote this garbage?" only to do a git blame and find out it was me 6 months earlier. 😏
Really liked point 5. I did a major refactor of a small module several months back. My instinct also told me not to raise the point to the project manager as they would reject it / not want to spend budget on it, but I knew it was necessary. However, I am not a part of the budget negotiations and wasn't able to allocate extra time buffer on other tasks that I could use to spend time on the refactoring. I think that was something I needed to make more clear in hindsight. I ended up squeezing in the refactoring, but I probably spent at least 40-60 hours of my own time over the last 6 months of unpaid overtime to complete the refactoring. It was ironic, because even as I was refactoring it, we were getting tasks that required new extensibility which was only possible because I had already partially refactored the older limited code. But unfortunately since I wasn't a part of these talks, I wasn't able to communicate that refactoring would be necessary and therefore more budget. But it was definitely a good timing initiative on my part to have begun it before then, so we could even complete the tasks at all by the deadline.
Still, it's something I need to manage better next time, so it was good to hear a possible structured approach here. I really liked the idea of discussing ways to spread it out over the upcoming tasks, and also the verification that it's better to not leave the decision up to the project manager by telling them you want to refactor. I was a bit torn on the matter as if I was secretly doing other work that hadn't been formally requested yet charging it to the budget. I think in the end though it turned out to be the right decision.
Also, the guitar is relaxing and fits the theme of maintaining a destressed, healthy mentality. It's a nice touch to interpose it now and then.
Why? why would you work overtime for free? otherwise you're just acting as a junior dev with no life
@@alexisfrjp I learned a lot about the code I was working with. I don't do overtime unless its a project I'm interested in, basically something that can teach me new things.
Big fan of creating a UI and code reference project with fleshed out, working examples of the tech stack, UI design, patterns, and shared libraries/services.
This can act as documentation along side being a working example of how all the moving parts interface.
I find this far more valuable than just a wiki of documentation, diagrams, and isolated code snippet examples.
It saves a lot of time on boarding and not having to answer lots of questions about how parts actually work together.
It also reduces the amount of documentation you need to write because the code speaks for itself.
Documenting and reviewing the chosen design patterns is a very good point. Many devs just use them intuitively or not even realizing it, while others just don't get it why and where and what.
Nice. Would add that a senior programmer also improves developer experience, not only product features. Things like tooling, automation, ci.
Definitely appreciate where visual studio formats the code for you now. I remember when I had to format it myself 😂
I just found your channel. Really cool stuff, thanks! I disagree on the refactoring though:
a) It's strange idea that management is by definition unreasonable.
b) Refactoring tends to break things, so it's better to refactor one thing at a time, so it can be tested.
c) If something was broken by refactoring, and there is no ticket, it will take more time to investigate.
d) The approach of spreading refactoring on other tasks creates dual time tracking and kind of uneasy conscience.
The approach I use: if there is a task, clean the stuff around it, as it will be tested all the same. If there is a potential of breaking things outside it, open a ticket and discuss with management when there is the right time to do it. Formulate it in terms understandable to business: less bugs, better performance, easy to support, etc. Because "refactoring" without details may sound fishy to business. I absolutely see their point of view. Especially when it comes to young developers who just eager to try all the possible libraries, patterns, approaches, etc. and then leave for a job with higher salary.
I agree. I've experienced management of "varying maturity" for managing software development, and I find it also depends on the load on the team and project deadlines. In my experience, refactoring can become a hot topic, that makes management (and customers) uneasy, because;
- even the most crappy code has a somewhat known behavior, while if you think about it, newly refactored code is just as prone to errors as green field code, even if the code structure is better than before, and some old errors have been fixed. Introducing risk into a project or product without informing management can put them in a bad spot in front of the customer, and decrease their trust in the developers.
- some developers feel the need to refactor, because it is easy to see what the current code is not able to do, but often we miss what the existing code might actually do very well, or some special case scenario handled, and that does not get translated to the refactored code. I find we can sometimes be a bit too confident in our abilities to really understand what we are refactoring from.
- I've seen customers reluctant to upgrade, even if their current version had bugs, because random stuff always appeared to break in the next version, with no notes of a change in e.g. the release notes.
- I feel we as developers are not always great at conveying the absolute necessity of a refactoring in a way, that makes sense for the business, but end up just being annoyed with managemen for not respecting our opinion. But the arguments presented often sound like "it's just better", "it looks prettier", "we've wanted to do this for a long time". I believe that a professional senior developer is able to explain and motivate a change for a (somewhat reasonable) management - explaining how a refactoring can decrease risk, improve performance, scalability, flexibility in features, reduce cost per feature for future tasks, etc. are perfectly valid, as you say, and if they can not be identified, maybe, just maybe, the refactoring is actually not warranted, and is more of a personal preference.
- I've also seen very experienced developers promise the business some improvements on a very expensive refactoring, that didn't actually happen / pay out. No sensible management will or should want to allow a refactoring after a stunt like that for at least a while.
That being said, refactorings are definitely necessary, should probably be done in small increments (maybe using e.g. the boyscout rule), and yes, in the end we the developers need to take responsibility for the code, and in that, do for the code what we see fit to hold that responsibility.
I think your comments are interesting regarding refactoring. I think people generally accept that refactoring happens without tests-you rewrite some or all of the code and just hope that all the logic is basically the same. But even though this is how people generally perceive refactoring, the books on it (including Fowler’s Refactoring) describe a rigorous process of placing components under test to pin their behavior and only then restructuring the code. They also talk about doing this for good reasons-maybe you need to fix a bug or add a feature, and to do it you need to add tests, and to add tests you need to refactor. If we were all using the by-the-book definition of “refactor”, I don’t think it would even be a conversation, and we would naturally be satisfying the aspects of refactoring that you like!
With all respect, but I think most management is mediocre at best. In my 40y career I've only seen four very good managers. The rest is completely clueless or needs vast amounts of pampering to get them into gear. So no - I don't think it's a "strange idea". It may be true that most managers consider themselves the best thing that hit this world since sliced bread - but that is a misconception.
Refactoring doesn't break code. As a matter of fact, less well factored code will break more often and becomes more and more expensive to maintain - according to a Bell Labs report. Every programmer knows that you change one thing at a time - just to prevent such an occurrence. However, "refactoring" may hit a large amount of code - that's WHY it has to be refactored in the first place. Hence, the effects may be wide spread.
The rest are just consequences of dumb managers who don't understand that internal code quality is essential - now and in the future. And if you're stupid, yes, those are some of the consequences you have to bear. Trying to put that on account of the guys who have some pride in their work is one of the tricks stupid managers will try to pull in order to keep their position and save face.
I've been a consultant for 25 years and I hope youngins watch your channel and learn. I'm not a developer, but I know everything you say is spot on. Especially documentation and standards.
But my illegible code is job security.
Not if management is smart. 😉
@@JayEdgarTthat’s a good one, you’re funny
I know this isn't technically writing code directy, but it effects it indirectly by writing less of the wrong code, so I would add "asking alot of questions", including possibly stupid seeming ones, both in general but especially during any planning/design/anaylsis. Drilling down into things like customer requirements and possible design issues early one can often uncover and solve problems before they even arise. This can save a ton of time by simply not having implemented unwanted or unworking code in the first place or having to rewrite code multiple times, because you just keep discovering that there was a little more to it. It can also push the customer into analyzing and defining requirements more completely and earlier, like when a question they haven't even thought about yet comes up.
Absolutely, asking questions and listening are super important at any level of development. Great comment!
I agree diligence is a good attribute of a good programmer. I think debugging code is important as well. And I guess it works for the overall process, is to move in small increments, fix one thing, write a little bit of code, watch it go green, or how ever your team does things, just don't do a lot and forget where your going. I know when working on personal projects, there are two versions of me, one that just starts banging away on the keyboard, no commits, no tests, no refactoring, and 200 lines later I got soup. Then there is the me that opens a branch, writes a little code, commits, checks it out, refactor, maybe I push it, rinse and repeat, ...the point is going fast usually never works out , go slow and diligent and you will go well.
As a retired software engineer with about 40 years experience I agree with most of what you say, especially about continuous refactoring. On one big project (about 6 million lines of C++ back in the early 90s) we did a 3 month release cycle and the QA team decided to look at the check-in rates. They found the average team member checked in around 3000 lines of new code. Our most senior programmer checked in -5000 lines - yes, 5000 lines less than he checked out, while adding serious new functionality. He also published a checklist of refactoring items that other teams should apply on future releases but with no use-cases or user stories etc attached. Just good practice.
6 million lines of code? Oh boy...Did it take "every long" to compile that monster?
@@hicknopunk A full build took between 4-6 hours. We used a home-brewed distributed build system across 4 Sun servers. Not the longest build time I've worked with, that "honour" belongs to a PBX control system built on a DEC Vax which required over 24 hours. It was built over the weekend once a week...
@@alangauld6079 I am sure it would take ages on my IIci or my 386 DX I had in the early 90 🤣
I noticed that some of the pointers here such as incremental refactoring and documenting patterns have recently applied to me and I think it just stems from thinking about reducing technical debt such that time can be spent on implementing features, and making it easier for the team to work across various code bases. This is an insightful video, thanks for sharing!
100% agree with everything you said. Its tiring working with developers with 10+ experience who don't get that those abilities are the most important. A developer is a digital counselor, not a simple programmer who should copy paste the best standards just because others say this is the "best thing" to do. You should ALWAYS have a sense of "technical diplomacy" . It's about having a minimum of professionalism in my mind. You can't be a good developer if you are not: transparent, critical, capable of putting yourself in other's shoes, thinking about business implications of what you do, blindly thinking about "best practices" without looking at the actual needs and how to transition properly to the proper solution.
It's pretty much totally unprofessional to lie about what work is needed. And lying is what is being advocated in parts of this video. It's no wonder programmers have difficulty being taken seriously. If major refactoring is needed to make a new feature easier to implement and more reliable, then that needs to be stated explicitly. Pretending a feature is going to take six weeks because it requires massive documentation and weeks of refactoring isn't helping anyone.
@@loganmedia1142 You didn't listen to the video properly. Listening to the "prevent unfinished work" he says to be straight forward and explicit about needs.
2- Programmers have difficulty being taken seriously because they speak in "geek" terms without caring enough about who the listener is and how much they understand. Also developers are known for being very "needy", because many don't want to do anything but code (which means no documentation, no recruiting, etc...). Because most are too "focused" they lack vision and proper understanding of the priorities. I'm a programmer, I see it every day by experience how much developers disdain proper documentation and thinking about those who are less experienced then them.
3- As for refactoring, you might think its not professional to not say anything, but in my opinion its the exact opposite given the current reality. The reality is most projects are managed by people who don't care about tech and THEY decide what you do on a daily basis despite most of them lacking the will to understand your point. So why would you waste time trying to explain and get your ideas validated by people who will never be able to truly measure the issues until its too late ? Just don't , its your work, you own it, its your responsability so stop asking for validation and just do it !
I rather work with a developer that knows how to take initiatives and makes mistakes, then a programmer that does nothing except what he is told and does it well. Because the first goes way beyond just giving advices, you can trust them to tell you when things are truly going bad because they will only talk to you when that is the case , while the other ... lets just say you'r already lucky if they give advice (not to mention its usualy bad advice most of the time because it lacks corporate vision, so they wait for your approval every time making their boss responsable for a work they don't even understand most of the time ). Professionalism isn't just about transparency, its also about knowing when to take risks, and its actualy this very risk taking that shows the difference between an inexperienced and experienced developer.
love the points you make in this video, there's a theme of patience and thoroughness running through all of your tips that just exude wisdom. what especially surprised me as a junior developer is hearing how universal some of these things you describe are, I found myself thinking yeah, there's people on my team who have done this or that and I've definitely been guilty of a couple of those things (especially the being done with 85%-90% of the work thing but saying it's done thing! wow)
Glad to hear it helps! Just trying to share the stuff I wish someone told me when I started out. 👍
Don't be afraid to go back and add more tickets/stories as you discover things that were not captured in the requirements or we're missing. You always have to make sure every requirements, changes are captured in the ticket. If it's something small then you can just update the ticket and inform the requester before working on it. Yes your scrum Master may not like it however it will help him understand how much work you're taking on.
I totally agree on this. Even if it's technical debt. That's because any change in the code has potential to negatively affect a functionality. By raising it as a ticket, the affected functionality could be QA tested. No bug suprises because of untested code. Unless, your code has 100% automated test coverage.
In most companies I worked for, this is actually encouraged. And it’s not up to a scrum master to “like” it.
Glad to see you're making videos again!
I just love these topics you have man. They're day to day experiences I have and I can't really talk to anyone else about them in my life. Glad it's more frequent than I thought.
1, finish the task, good call, you will never have time to go back.
2, write tests, tests, tests, tests and more tests!
3, write readable code
4, never ever give a full estimation, just give an estimation on the first deliverable feature, that includes time for unit tests
5, more tests, this will save you!
Formatting, patterns is something is a company thing that’s usually already specified.
Generally, you should follow the formatting, code style of the codebase you’re in. unless it’s your task is to rewrite it.
Focus on writing good code, good test, let it known that you will not be available for sales meetings. Once you start wearing a few hats, you can’t focus on code
Some observations I've had over the years...
First write the program/feature without writing a single line of actual code. Plan the structure, objects, interfaces, patterns, etc. ahead of time. Once you know how the code is supposed to be structured and function, then write it. After years of writing code you find that "writing code" is the easy part. It's the thinking/planning/designing/structuring/etc that is the challenging part. Do that before you write anything (besides prototyping and proof-of-concept stuff).
I see people start to write code on day-1. They spend hours or weeks writing code and then go back and rewrite their own code because they found roadblocks or discoveries that lead them down a new path. Some don't go back and rewrite but end up with a design that can't be extended or easily modified as the business needs change...which leads to re-architecting later.
Proper code structure/architecture helps make code easier to understand as well as update. I've worked on projects where a single WinForm had over 30K lines of code. Or a repository class will be named at such a high-level that it contains 60-70 functions that pertain to 20-25 different features; instead of having 20-25 different repository classes.
Some people strictly follow a canned methodology or architecture instead of tailoring it to meet their needs for the specific project they are working on. Sometimes poor choices are made because someone is trying to adhere to a strict rule when they should have allowed an exception to the rule (documented of course). Understanding "trade-offs" is an essential aspect in software.
Also...always keep dependencies in mind. Sometimes classes or groups of classes are tightly bound together...and that's fine and mostly unavoidable. But do try to keep things into relatively isolated groups or units or components. If something needs a major change, you are essentially limiting how far that change can affect the rest of the code base.
Another important note: Be open and honest about your code, your vision, and your choices and humble yourself; never belittle somebody. Everybody is on a different path in their practice. I've seen people with a decade of experience, yet they're still at a near-junior level. It turned out that they were at a single job those 10 years and never really had a senior person to learn from. Others were fortunate enough to be working with a team of advanced senior people who shared their skills and openly mentored. Sometimes they just needed to be surrounded with a good team; but then sometimes they had no interest or capacity to improve. It's worth giving them the benefit of the doubt. Even truly senior people have an unending amount to learn (and they often enjoy engaging in deeply geeky discussions). This is a profession that will never be complete; we are always all just perpetually "practicing" it.
Yes I am starting a new project and it really demands hard thinking about how to structure it. I am calling it the research phase of the project. I will be mixing technologies with some unfamiliar techniques too. What do you call your plan docs? Design documentation maybe?
I bet you have a math degree :-)
"Some people strictly follow a canned methodology or architecture instead of tailoring it to meet their needs"
This is a huge one, I think this is one of the biggest problems in the industry right now.
Essentially:
1. Stop not documenting things.
2. Stop not communicating with your team.
3. Stop not treating the last two things as core parts of a task or you will continue not doing them.
Gonna write that on a sticky note.
I think the most important point he made was "know what and what NOT to point out to the manager team"
Oh and FINISH the code! 100% FINISH it...
When you try to prevent management from making bad decisions, they push back and let their egos get in the way. 🤦♀️
These are excellent pieces of advice. I have a specialist/senior team member whom I admire, and they follow every single step you've mentioned. Thank you for sharing!
Glad it was helpful! Thanks for the feedback.
All of you in the comment section and this video have added a lot of value to my knowledge in just 15 minutes. I am a freelance full-stack developer, and as a beginner, I make a lot of mistakes. However, despite being a beginner, I always take responsibility for delivering a better product. This thing will definitly help!
As a Scrum Master, I appreciate your thoughts very much. I especially liked the points about refactoring (I agree with you make it a standard part of your work), collaborating on new patterns, and DOCUMENTATION. I would much rather the team finish what they started than build up future problems for themselves. Technical debt destroys healthy momentum. Thank you for a very thoughtful video.
You're very welcome! These videos are definitely meant to be of value to all people involved in delivering software - not just programmers.
I love the "As professionals we cannot let that happen" argument.
Nothing describes Senior Engineer better than lying and hiding things from "Management".
Great advice.
It's not really hiding things from management, unless you like being micromanaged. Just like you wouldn't submit all your draft hand drawn problem solving you used to refactor; it's composite to the process. If they ask, tell them, but it's details they don't need to know about only means slowing things down to explain what they should be entrusting the senior dev they employ to handle on their own.
It's hiding things, plain and simple. This is BAD advice.
The better solution is to JUSTIFY the refactoring. Refactoring for the sake of refactoring is usually bad and hard to justify. But if you can justify to your management that this will reduce costs and/or is required to support new required features, that's how you task it in your tracking software.
I don't normally comment, but as a senior manager I say please don't do that. I have to trust you. If I don't you won't be around long. Frankly I don't have the time to micro manage. I rely on my seniors to lead the mid and junior level engineers. I completely understand the impulse to feel ownership of your work. I have done it too. But you don't own the code and it is possible they know about things you don't and are making strategic decisions they have to. So honesty and frank sharing of your concerns are much better advice.
@@ericwill1747 unfortunately there's so much more than just "reduce costs and/or is required to support new required features" and only a senior developer will really feel what those are. For example, junior developers are learning on the job mostly from the code itself, so if you want them to up their game you need to factor out the bad teachers. Also, you're asking a junior developer to put a dollar value on a refactoring effort is stupid. We cant even estimate time, how would a novice estimate value?? That's the whole point: senior developers have a sixth sense for technical direction. Bad code has a "smell" etc. Don't put your refactoring up for discussion with people who have no understanding of these things, because they WILL feel compelled to make a decision about it and like a horse and cart falling off a cliff you will imperil us all!
@@delanym As a lead engineer (which I am), I would not be happy if this sort of work is hidden from me. As you said, a junior engineer cannot yet be trusted to make these types of decisions accurately. And taking longer than I expect them to do it will probably look bad on their review too. I would expect such a junior engineer to come to me or another senior engineer on the team to figure out
1) how much longer the refactoring might take to implement
2) how risky is the change (and how much Test needs to reverify everything)
3) what we expect to actually gain from the refactoring (performance, future maintenance time, easier understanding of code are all perfectly acceptable reasons, not just money).
Once we know that, it's up to the lead to decide whether the cost of the refactor is worth it.
I would praise a junior engineer that came to me with these suggestions, even if they weren't valid, because they are at least trying to think about what's good for the project.
Debugging Methodology is really important and when I was a Junior engineer that was really my wow factor from the senior engineers.
During an incident or an problem to have a senior engineer be able to methodically walk through the problem and code in a confident manner and ask good questions really seperated them from the rest of the Juniors. Even Seniors who just joined our team would be able in a few days be able to debug critical issues and problems much more efficently than I could at the time.
I think the paradigm that I've developed for debugging in this regard is just understanding how each system receives its inputs and returns its outputs and being able to articulate that well to others either in written form or in verbal form when walking through the codebase. Then understanding the limitations of each system at a high level and being able to explain their purpose really reduces debugging which Junior engineers don't really have since they have so many new products to learn and understand.
Very good point. I've seen people waste hours just because they don't know how to use a debugger properly.
@@MrTridac Using a debugger isn't the same as debugging methodology at all. e.g. on a distributed system where the bug only arises across nodes - good luck making use of a debugger there :) (though you could record memory and then analyse it afterwards, if you need that the logging was likely not up to scratch)
@@Bozebo That's why I prefer tracing. My code usually writes extensive log files when in debug mode. I also constantly change the things that get logged to chase bugs.
In my company, the ones that move fast who get the features implemented (by creating tonnes of tech debt) get the promotions, as they are the ones that are noticed by management. The ones that push back to create better documentation, have peer reviews and plan refactors (to fix all the crappy code) are the unnoticed ones that never get any praise or promotions
I remember spending 6 months writing a very good custom data grid (since for specific reasons we couldn't use Kendo or any other data grid our company approves us to use), then 2 months after, the company approves us to use Kendo again and my 6 months is gone. It really sucked...
Writing good code is a great attribute of a senior programmer, but I think the ability to read bad code and work with it is even greater
Excellent point. You've probably heard it said that most programmers are better at writing code than reading (even good) code.
When I started really trying harder to understand code before I would make any changes, I found the job MUCH easier. I was too quick to rewrite my first 5-10 years in.
If people write good code. No need to spend time one hardly reading bad code. What should be promoted is "writing better code"
While reading bad code is essential because you will get a ton of it from less experienced engineers. I think an even better attribute is to be able to read/follow code in languages you aren't familiar with.
Those DIY guitar interludes are really cool.
Thanks! I wasn't sure how that would be received but so far, so good. I've got some more ideas for how to incorporate more of my music into this too.
100%. One of the things I always do (if I have the control) is to setup formatters and linters that are triggered as part of testing in CI which then automatically surfaces when code deviates from the standards. Individuals can write in whatever style they want but if it doesn't pass the automated tools then it won't even make it to PR.
I will say though that I've worked with plenty of other "senior" (cough - title inflation cough) engineers who have disagreed wildly with some of the practices mentioned. Used to be "self documenting code" (that never was) and now it's no documentation at all. Not even useful comments (the number of times that I've flagged comments for looking more like "notes to self"...what about the rest of us, what do we need to know?
Overly convoluted code that tends to demonstrate how clever a programmer is. Premature optimization in some places and yet in other places not thinking that a quickly growing dataset can't possibly be loaded into memory in its entirety (I'm literally referring to loading the entire results from a query and then manipulating, potentially making copies, etc.).
I really think a couple of huge problems I've seen in this business (at least in Silicon Valley) is the abundance of arrogant, relatively inexperienced programmers (now always called "engineers") who not only have benefitted from title inflation but because of it think they're smarter than those who have more legitimately earned the title through the sheer number of projects that have been worked and with a depth and breadth of expertise.
Some great points here. I'm going to do a future video on how modern society and its obsession with youth culture is destroying the software industry. Stay tuned!
Comments should explain why. Code explains what.
I did share this video with two Software Engineers in my team who are getting promoted to Senior Engineers and they absolutely loved it!!
Thank you for the advice. I've written code since I was a kid, but I'm only about a full-year into my first development job. I've always thought I've written good code until my lead constantly revises what I wrote. I'd really like to grow as a developer and show them they made a good choice. I really enjoyed your style of teaching. Definitely subscribed.
Welcome to the channel! And best of luck with your career. I'm sure you'll grow just by being on a project - we all do.
13:37 video length, well played. I would agree on your points even tho I am part of a long lived team. Good advise
On documenting chosen patterns (chapter 3):
If you don't know where to start, I recommend the Architecture Decision Record (ADR) format explained by Michael Nygard's "Documenting Architecture Decisions" article.
ADRs made it easy for me to document architecture and design decisions and patterns. I think ADRs are a good way to do what the handsome man in the video demands by 'document chosen patterns'.
"I'll come back to it later" ... No, you will never have free time to go back to anything.
This actually validates a lot of the things I've been pushing in my scrums, glad to see I got that senior title for good reasons.
What you've said here about adopting new standards and slowly rolling those out across the code as you maintain it... It's exactly like what the Netherlands did with their cities. They implemented new street and road design guidelines, and over time as streets needed maintenance those codes were implemented. Now they've got well designed streets with all kinds of safe infrastructure and bike paths, and they didn't need to spend any extra money, it was all part of the maintenance budget.
Very interesting points. It boils down mostly to discipline. The point about refactoring and managers particularly resonated with me. Managers seldom care about enforcing discipline,... I have seen many projects going into a wall because of that.
Don't let yourself get eaten away by them. When they always have the final say, it can be better not to give them a chance to speak at all. They don't need to know exactly what you do: they just need to know when each given feature will be ready. Give yourself the time to do it right, because they won't.
i think it is a good practice to measure refactoring time and include checkbox for it on your story. if the manager doesn't like it, the problem is that the manager is an idiot, not with your organization practices :D
Discipline is everything for non-creative work. But when overdone, it may kill creative potential and make work mechanical and people passive agressive.
why would you care? it's their responsibility as long as they are aware of it, but I agree, they don't need to know what you're doing, depends on the company tho
Great video 👌
One thing I'd like to add about refactoring tasks.
I used to do as you said, but I found that this is really limited to everyones active memory and therefore difficult to follow through.
What I now do instead is - I create relevant refactoring subtasks under a tickets with other sub tasks. This ensures everyone remembers to do it and also communicates clearly to the business stakeholders why is a refractor even necessary. It also helps to distinguish actually necessary refractors from the ones where you just feel like it should be refactored.
This of course only applies to notable size refactoring. For small reactors it's just a part of the task.
Ahh you're getting ahead of me :). Yes sir!! On a team where it's safe to make refactoring visible, we do this. But that's to help the dev team keep track of the refactoring progress and make sure it gets done. Not to report it to management! Thanks for leaving this comment, I'll talk about this specifically in the future!
Great info
I've become really passionate about documentation, but as a less experienced dev I'm constantly haunted by the idea that "your code should be clear and self explanatory" and although I don't feel that I'm relying on documentation to explain my bad code, I worry others will think that's the case
Totally understandable. Just keep documenting to the level you think is important. It’s better not to walk a tightrope without a safety net!
Most experienced devs will ignore the comments, so make sure your code is good. So long as your code is good, no one will accuse you of using comments as a bandaid.
@@jgnhrwhas that really been your experience? I don't doubt that it has. It's just interesting because in my case, at least in the consulting world, the more senior technologists always use the comments (and documentation) to get as much information about the solution as possible. Different strokes for different folks I guess.
Amen, brother!
One thing I noticed: Highly skilled programmers sometimes are sorely lacking in communication skills. They produce insanely complicated code, often not on purpose, while disregarding that they probably won't be the person maintaining it.
Bingo. Your code becomes someone else’s at some point! The it gets down to whether you have empathy for the next owner.
My company doesn't let us individually point stories, it's a collective and you can say this user story is 8 points, but if the rest say it is 3-4, it usually becomes a 3 or 4 point story. Then oh look it is more work than they thought, it should have been 7 or 8.
You know you're senior when you get a discount at Denny's.
This is a stellar video. Can you please make this into a short somehow - especially incrementally refactoring
Great idea! I'm releasing shorts on Monday and Wednesday. I think your suggestion makes perfect sense from this one.
In case you didn't see it here you go: ua-cam.com/users/shorts47UafqGMzDA
@@HealthyDev amazing, now I can share this with management and help make that impact
Totally started coming to the same conclusions recently, and this just gave me a bit more confidence to commit more to getting things actually done, much appreciated
From one Senior Dev to another, This is all spot on! Especially the "almost done" part. Think SSD here too.
As a senior developer I have made it a habit to reject any comment that says "TODO: Bla bla bla" if the comment doesn't reference a concrete work item or user story where the undone work is specified. It comes from being frustrated with opening decades old files with legacy code that has TODO comments that I don't understand the details of and all the people who were in the company when that comment was made have since left. I feel like having a T-shirt printed with a picture of Yoda and the text "Do or don't do. There is no //TODO".