Don't try to "beat" anyone in speed etc. and try to focus on collaboration instead, or you will generate resentment from the person you "beat", you really don't want. Don't be crazy possessive about your code. Your "perfect" code could be changed by someone else and getting all pissed off about it is incredibly annoying to everyone else. Be very thoughtful and caring when pointing out someone else's mistakes. Point out that you have also made the same mistakes in the past. Proposing innovations and improvements could land you into conflict with the person who was responsible for the code or the process you suggested could be improved, because he or she didn't think about it first. Make sure you compliment that person's efforts first.
Growing from novice to a better developer is not about reading a lot of beginners' books, watching a lot of tutorials or going to a lot of courses; it's a slow process that imply **doing*: Make a lot of programs, say, *solve** a lot of problems, and **make** a lot of mistakes. It could seem overwhelming at first, but it is an exponential grow. Not only solve the problems you have **ordered** to solve: Find similar, simpler problems and solve them. The insight so obtained is the oil that will make your solving machine go smoother and increasingly powerful.
I have a saying in my shop: "The user doesn't know what they want until you show them what they asked for!" This is an essential part of the requirements gathering process. By building an early/quick prototype version of a system that represents your understanding of the user's stated needs, you establish a 'common ground' or 'context' from which to grow the real understanding of the requirements. And as a bonus, the user feels more engaged in the process as well.
I want to reinforce: if you say you are done with the task, but when asked if you tested, your answer is no, then you are not done. You are not even half done. You barely started.
Don't be afraid to ask colleagues for help. More often than not, someone you work with knows as much or more than you do, and they are as or more worthy a resource as a bookshelf, or a Google reference. Even senior-level people ask questions and yes, sometimes they ask dumb ones. Outside forces can affect someone's thinking: C19 human malware, family matters, and so on. And don't just ask for coding help, all the topics are valid: design, user desire, business rules, etc. Ask for help when you need it. Ask for context when you need it. I would suggest taking time to research the problem you need help with first. It does get embarrassing to ask a question only to answer it yourself the moment you hit send--but senior people have been through that. Still, it happens. I'm not going to deep dive on the, "what if I ask too many questions, will I get fired?" route. The truth is you'll always be evaluated. Generally when you're hired, the company has a good idea of what you're capable of--also why most companies have a 3 month probation. Learning the company's software for example will likely be an initial role, and sometimes asking questions is expected, and not asking questions might be the wrong thing to do.
*Timestamp* 1:50 1. "SW Dev is all about Coding" 3:50 2. "If only the Business would get the requirements right!" 7:08 3. "Speed is all that matters!" 9:22 4. "My Job is to Code, Not to Understand the Problem Domain!" 11:05 5. "I can't ask for Help! It shows that I don't know enough" 12:18 6. "Software Architecture is for the Experts!" 14:00 7. "Testing is someone else's job!" 15:20 8. "I would like to do a better job, but my boss won't let me!"
Kind of similar here, writing software for some years, and unfortunately in an environment that is not quite state of the art concerning tools and methods. So there is a lot to improve (at least superiors are open for these). Continuous Improvement, both on an individual and on the company's side...
You realise you've grown up when you realise you made those mistakes, and you try not to make them again, knowing the consequences. Eventually, all of those mistakes were made, and you can finally enter adulthood.
I've found that changing the question is a great way to find a solution that works. Never start by asking a customer what they are looking for, start with, could you describe the problem, or show me what problem you are running into. Not only will they willingly give you more information, everyone likes to complain, but you might be able to fix it in a way that gives them more value for less work. If not you can always follow up with, "and what do you envision the solution looking like." if you are talking to management, or "what can we do to fix it for you." if you are talking to a lower-level employee.
Yeah he earned a sub just because I have struggled with getting my foot in the door of a development job and I feel like his wisdom will be invaluable in building if nothing else my self confidence to make more so I can flesh out a better portfolio.
“Smart people ask questions, dumb people think they have all the answers.” Spot on! I was brought up on, and have successfully lived by the thesis “He knows the most who knows he knows nothing.” It’s where we all start and what enables us to learn.
I've only watched a few of your videos, but I'm liking your content so far... In this video, for example, you have covered many topics that I have been preaching for the past decade, and It is heartening to finally find somebody else on the same wavelength. I have been working in the manufacturing business systems field for many years, and have had many of the experiences you described, and my real frustration is the fact that most organisations don't want to even acknowledge these issues, let alone change to a new way of thinking and working on I.T. projects. My company takes the much more modern approach to developing software - the main being that we do NOT think of ourselves as software developers - we are actually "Business Problem Solvers" - and computer systems are just the TOOL that we use to solve those problems. If you concentrate on actually solving the problem and improving the business, there are very different priorities. We find that if we stick to some simple principles (inspired by agile software development principles, which in turn is inspired by Lean manufacturing and Goldratt's ToC): 1. "Capabilities", not "Requirements" Concentrate on the overall "Capabilities" that the USERS need to solve the PROBLEMS - let the developers figure out the best way to deliver that capability, rather than insisting the business describe the requirement in real detail. i.e."I need to be able to take photos on a building site and automatically put them into a report template for our client" 2. Small batch sizes - develop and release capabilities in short quick chunks 3. Short feedback loops - get the developers talking to Users directly, release, test and refine a capability in as short a time as possible - preferably in hours, not days or weeks And in general, for solving business problems, the answer/system generally needs to the same simple things: 1. Make work visible 2. Be able to see any Business Operational problems quickly (and to "swarm the problem" as the famous saying goes) 3. Create communication "Protocols" between employees and teams - give the conversations common language, structure and methodology - reduces errors, confusion and waste. I think we sometimes forget that this whole industry used to be called "Information Technology" - as a society, we've concentrated so much on the Technology part, we forgotten that the actual reason that all this exists is to improve how we use and transmit INFORMATION - and this couldn't be more important than within a complex business. As software developers, we have the potential to MASSIVELY increase productivity in this country, if only manufacturing and business would adopt some of these simple approaches to using technology in their operations. They usually have a board of directors that includes representatives from HR, Health and Safety, Marketing, Sales, Manufacturing.... I have yet to meet a medium sized manufacturing business in this country that has a technology expert on their board - it's simply viewed as a "Service" like payroll or the canteen, whereas in this day and age - a real business strategy IS a technology strategy. My company has set out on a mission to change this situation by developing software that solves real business problems quickly and continuously, and finally get I.T. professionals "A Seat at the Table". James Hathaway - Technical Director at SigmaDX Ltd. Resources that insipired this post: Eli Goldratt - his entire Theory of Constraints master work. "The Phoenix Project" - by Gene Kim, Kevin Behr and George Spafford "A Seat at the Table" - Mark Schwartz "Black Box Thinking" - Matthew Syed (Better to fail fast and learn than to be paralysed by indecision) "Lean Startup" - by Eric Reis "Toyota Kata" - by Mike Rather
If you want to help the channel, share the video on the social networks. This man is giving you all the knowledge he has on a silver plate! Thank you very much for the video!
This channel is underrated! Thanks for sharing that much of good content. Coding in itself is "easy", thinking, designing, debugging, launching a software is at an another level.
Sadly, they keep stacking up the expected requirements for a job too. I think it would be better if the bosses would hire programmers from a few different experience levels and then a lesser programmer could actually get experience and the higher level programmers could have someone to take care of some of the grunt work.
I have a Master of Science in Software Engineering and I honestly wish I could go back and replace my coursework with nothing but the videos on this channel since it honestly would have had a more powerful impact than the standard curriculum.
I hope you feel you got your money's worth from school. It's lots of sacrifice to get a masters. I'm going through mine now. I would probably feel so jaded if I thought it was a waste.
@@kb3khs You don't go to college to learn new things; information is freely available to anyone and a teacher is only there for support, not to gatekeep knowledge. You go to school for a piece of paper that vouches for your critical thinking skills and lets an algorithm that processes resumes sort yours into the "review" pile instead of the "reject" pile.
With any career, it is important to be proactive. Don’t just sit there and only do just enough of what’s being told to do. Activate your mind, and always be curious at everything.
Being proactive is only possible when the culture is right, I'm currently working at a company where it is absolutely not appreciated. I've been yelled at multiple times for simply notifying the team about bugs.
@@unrealcyberfly , my advice would be to proactively try to fix the bug. Then, present to your boss the fix. In my experience, bosses don’t like complainers, just doers. It will put you in a great advantage as a dependable member of the team.
@Peter Tran In this case the bug comes from a colleague's output. I've cleaned up their mess before, no more! Colleague is the boss' sweetheart and hides "behind a lack of knowledge". --- I just needed a place to rant, thanks for listing.
This is good stuff. The business will never get the requirements right alone. A good engineer will work with the business to define the problem and the potential solutions. Writing code, incrementally, allows us to test with the business the best solutions. We are not two teams. Keep up the good works, subscribed!
I used to work with computational physics (fluid dynamics), and a recurring problem I found in the community was that they were very focused on marginal improvements in speed or accuracy, but not as much on the physics - for example, always running against simple test cases or making unrealistic modelling assumptions. Also, not very much focus on UX or documentation and making their tools accessible to a wider audience.
I didn't firmly grasp the concept of the finding solutions to the problem until my senior dev made me solve a problem without writing a single line of code. Basically using UML diagrams and logic to think through what was actually going on, it was a very useful exercise. Side note, I can't wait to get my copy of the continuous delivery book!
I think actively evolving communication skills is vital. Its all about language, text, discussion and understanding the requirements and problems. A precise, meaningful and structured communication is so important.
@Xiaoran Meng Just to add to what you said: The number of years someone has been a developer may be an indicator, but is certainly not a true measure of seniority. I have seen people who had worked 25+ years as developers, and still could not design anything non-trivial by themselves. Conversely, others needed less than a year out of university to demonstrate true talent. Remember: Having done the same thing for 30 years without constant learning, is not the same as having 30 years of experience. Instead it means "I have learned during the first five years and then stopped progressing".
8:03 Please also mention that using many many libraries that came from nowhere does not mean "writing less code". Once a dependency gets added in any form, WE are responsible for maintaining it ir at least upgrading it in the future.
8:00 about the fast typing: personally, I gain greater insight into the code by simply attempting a solution and then improving on it, rather than by, say, pseudocoding and trying to get at the answer by non-coding means. It's sometimes hard to oversee the nature of the problem without actually looking at some code that forms part of the solution, even if it's a suboptimal solution. I agree with most of what you say here but for me, working fast and typing fast are integral to my ability to focus and concentrate
Awesome content, thanks. IMHO, you can strike "junior" because some of these mistakes (especially the last) I can see long time professionals do as well (who might think of themselves as seniors)
Hi! Love your content! Could I suggest you add time stamps to the description to add book marks on the RUclips videos? For instance: 0:00 - intro, 1:48 - mistake 1: SW dev is all about coding, 3:47 - mistake 2: If only the business would get the requirements right etc... This is helpful so that viewers can jump to a specific point quickly in your video especially in a video with a list of items. I love the refactoring series. It's actually quite satisfying trying to make code cleaner and concise.
0:00 - Intro 1:40 - SW Dev is all about coding 3:47 - If only the business would get the requirements right 7:08 - Speed is all that matters 9:21 - My job is to code not understand the problem domain 11:03 - I can't ask for help, it shows I don't know enough 12:17 - Software architecture is for experts 13:58 - Testing is someone else's job 15:18 - I would do a better job but my boss won't let me 16:42 - summary
@@ContinuousDelivery no worries! Please see the above message for the complete time-stamps for this video. I believe you can edit the description after posting and it will update the timeline 👌
Randomly found this channel. Found out that, on many points, I tend to think a lot like you, despite being in this business and in the same company for roughly 7 years, meaning that I lack a lot of experience. I love this and will most likely spread this among the colleagues, some of them definitely need to hear this =) Thank you for this.
All your points are 100 % spot on. Believing the client will provide a substantial and useable blue print for the new application is particularly bad. You have to take time to understand their business and take time to come up with the best solutions, which might differ significantly from what they think they need.
4:23 I don't fully agree about the business. I wouldn't say, it's the job of the programmer or the business alone, but the programmer has to find out by talking to the customers while making suggestions and clarifying, what would be possible. Else half of the code will have to be rewritten because the customer doesn't like it.
To extend the carpenter metaphor, it's common to see younger people arguing about what amounts to whether cutting the wood or fastening it together is more important, when any experienced professional knows the important thing - and the thing you'll spend the most time doing - is MEASURING the wood. In software development, people will argue incessantly about whether it's more important to design the code or to write the code, when the experienced professional knows that while both of those are critical... you'd better spend most of your time TESTING the code.
An Addition to the "ask for help" advice: Ask different people the same question, even if you think you understood it well after the first answer. You will most likely get to learn another point of view on that same topic and understand it even better. Same applies for online research, always have a look at different sources. Also dont worry about wasting peoples time, you might even do them an indirect favor! Explaining stuff is imo one of the best theory practices one can have, even if its just refreshing already familiar topics.
I really dont know how until know I find this channel.... I have been looking at videos about programming since about a year now, trying to learn by myself and doing some minor projects, and until now I find this gem.... Thank you alot for all the info and all the information!! hope your channel gets as much as you which for it!
Yea, I'm a test automation engineer and a lot of things mentioned in this vid are applicable to software testing/test automation. I'm gonna share this with my co-workers :)
just a note about knowing the problem domain, I do optimize, debug and improve lot of system without really knowing the domain at all, because I concentrate first on refactoring/cleaning the support material, libs etc. So many code are badly written, a lot of time optimization is ENORMOUS by reworking the inner algorithm (like changing a bubble sort to a quick sort improvement) one of my last dramatic change was rewritting a SQL query that was written by an Oracle DBA, with all kind of obscure command and attribute proprietary to Oracle, I just clean it back to the originale intents, write the proper query, with trigger and precalculated value so the 12 hours report dropped down to 15min ... without any specialized oracle commands, my query work on any SGBD with minimal syntax adjustment! Combine this to the KISS principle, and optimization and easy maintenance is usually the results. But I guess you need to be a bit more experienced before attempting that, too many employer got burn by eager junior to 'rewrite stuff' .. but if we didn't reinvent the wheel, we'd still be on wood wheel... With experience you start 'smelling' the poor code that would gain a lot by refactoring/redesigning...
So many good points to think over for me as a junior dev. I alway find it difficult to ask questions, not because I don't know the questions to ask but mostly because to not be seen as annoying. Combining this to the point of taking the ownership, I will try not to feel intimidated for asking the questions.
I discovered this channel only a few weeks ago, and I am stunned by the quality of the content. In my opinion, all the videos are must watch for any engineer that cares about their work regardless of seniority. Thank you for making such great content available to everyone Dave.
About your last topic, addressing issues with management it is relatively a lot easier for a someone senior or someone with other options. People don't choose to not write tests or not to estimate right. These things could just so happen to be there. This is a lot more sensible topic, and I don't believe standing up works often, specially for Juniors and smaller companies. Of course this is often used as an excuse to not take ownership of a task, but lots of places do have a crappy work environment and won't let you do a better job indeed.
8:00 I love that you would say that, as when I think fast and am awake I type fast and make big changes on the fly all working, but when my brain is chilling I'm gonna have a really long time typing one word, like a cold engine unable to warm up.
The one I often see is following oft touted rules like don’t-repeat-yourself dogmatically, rather than pragmatically. The pros and cons of following any given rule should be evaluated when applied, because sometimes the extra complexity to the system isn’t worth the stated benefits
Agreed, to every DRY sycophant, I offer AHA. The rules are there to handle things generally, doesn't mean they cover every case. While I'm ranting, less lines != better. I hate it when people play code golf with production code that's maintained by a team. Write for the team. Final rule, and this is one I find to almost always be true, premature optimization is a quick path to hell.
Excellent, excellent way of saying what the value of developers is in context of "the business not getting the requirements right". It shifted my perspective on things, and I will be sending this video to friends of mine just for that segment.
Recently discovered your channel and I'm very impressed with the advice. I'm a hobbyist dev looking to go pro as a full stack web dev. I never really used to write tests but have recently tried out a basic tdd approach and it was really interesting and helped me think about the problems I was trying to solve.
Great video, thank you! I'm two months into my first software engineering role and luckily haven't fallen into most of these traps... a few might be borderline though hah
At the age of 57, I'm learning software development. I must concede that your videos give such a broad overview of software development, that it makes it always more interesting. Great !
The last one is sometimes true though. One project I worked on I told them it's a 12 month project. They gave us 4 months and pocket change. Every meeting when they asked about progress I told them, we will not meet the deadline, we need at least 6 months extra runway. Naturally they would argue about the schedule not aligning with business interests. I told them this is a foundational system and surely that is more important than whether the release window is ideal - if so concerned, then push release back to next year and we can use the additional time to improve the system further... Never budging...
Wow! So much value in a 20 min video! I would need to re watch it again and again to truly understand the ideas completely. Thanks a lot for sharing your experience!
The part about "If only the business could get the requirements right," being wrong is something I learned early on in doing freelance 3D animation. It was my job to know more about animation than them. If they recommended I make something that I knew would look bad, make text hard to read, not convey the correct information, etc. it was _my job_ to clearly (and politely) convey why it wouldn't turn out how they think it would, and come up with a better solution that would reach their desired outcome. Examples: Client says it's too dark and tells me to make the lights brighter; I intuit that they're saying this because the text is hard to read and instead make the background darker to make the text stand out; problem solved. Client says they want the camera to move faster because they don't want long shots of nothing; I realize this is probably because it's early on in the project and we haven't added the text the viewer will need to read yet; I add in the text without adjusting camera speed and the client thanks me for speeding up that shot. The client always gets the final say, but it's your job as the animator/programmer to translate what they _say_ into what they _want_
I can partially agree with this. Especially the statement that it's our job as developers to help the client express what they want in such a way that we can then implement their idea. However, I've run into scenarios where the 'specification' of what the product was supposed to do kept constantly changing, as it wasn't stated clearly enough. On the long term, this meant that there were cases where days/weeks of work were effectively flushed down the drain. Sometimes, the expression "If only the business could get the requirements right" does apply, even if mostly in the context of "then we would be able to deliver what they want in the time-frame we agreed on".
@@SuperPranx Oh absolutely. I've run into similar situations to you where I've been 90% done with an animation, confirmed that there wouldn't be any more changes with X, Y, & Z, and then around 98% had the client want changes to things that have been "locked," for months and required dozens of times more work that late in the project than they would have otherwise. Actually worked on a freelance programming project like this a couple weeks ago; specifications set in stone, finished it up, then the specifications changed. Super frustrating. I think the important thing to note is to not immediately assume it's the client's fault, but instead work with them as much as possible to reach a desired conclusion.
@@ZachHixsonTutorials Yes, I believe we understand each other :) And yes, it's not about blaming the client. It's more of a longing for that specification that is perfectly defined and doesn't change. A developer can dream... :)
He is absolutely correct about these issues. Someone needs to the employers this as from most of my experience employers are the ones that push a lot of these problems. You can see these examples in job descriptions and if you ever worked in the industry for awhile you would notice they tell you today but expected it to be done last month.
Great channel and great video. The beauty is that the narrator is actually talking in terms of principles - much of what he describes can actually be applied across the wider business.
This is kind of what is called "staying in the problem-space before going to the solution-space". Focus on the problem, the underlying assumptions, the whom and why, not the what or how. One of the biggest problems with us programmers is that we tend to jump directly to the solution-space. Some business person starts talking about a problem and 15 seconds later our brains have stopped listening to the problem and is instead filled with arrows, boxes, patterns and whatever technology we know. Five minutes later we don't even remember what the problem was, just that we get to write a bunch of code using nodejs, k8s, docker and NoSQL (because I don't have NoSQL on my resumé yet). What if the correct solution is to remove a feature, delete 10,000 lines of code and add a new step to an existing process/feature? Code is not an asset. Every line of code is a cost, a liability. It has to be built, tested, maintained, deployed, configured and operated. Programmers and code do not exist for the sake of their own existence even if we like to believe that we are. We are not getting paid to do our hobby, sitting in a corner with our headphones on, listening to "programmer focus synthwave mixes". Sorry.
Thank you for making this video. I'm making a career change into web development and these are helpful points. Fortunately, I've always been a very curious person and love learning things and asking questions. I'm hoping that will help me here. Have a good one!
First video I've seen from CD and subscribed at the end. I'm brand new to software dev but not new to the cybersecurity industry or general life/work principles and this video was spot on. 👌
I worked at a place where the clients often did not know what they wanted and when they thought they knew what they wanted it was sometimes based on false notions. I had a talent for explaining things in a simple manner that non-technical folk could follow and find out what they really needed even when they wanted something that made no sense. I am not sure if I should mention the last part of that to potential employers though. They may not like the idea of employees second guessing their clients' wishes.
Love your videos, titles sound like the titles from thousands of other clickbiat videos, but you actually give deep thoughtful and instructional answers/solutions!
3:05 I started to write software, which I actually use, so I don't think about if I would like to use this software, but I try to make it as comfortable to use for me as possible.
7:42 I almost don't type, when programming. I can type pretty fast, I guess, but also not too that fast. Most of the time, I have to rearrange code, which already exists, anyway. So efficiently using copy/paste is probably more important than fast typing. Or putting code, which you often reuse into a function, so you don't have to write/copy that much.
Great video! I am guilty of some of these. Really humbled me a few times. I used to ask a lot of questions then around my 3rd or 4th year an engineer said he always knew how little people know by the questions they ask(which is true) but so what?... I am so over the ego BS, I just want to write robust, clean, solid software.
I have one I learned early on: “It isn’t my job to explain or teach.” Is this mad? You bet it is. Eventually I will have to teach the team why I developed the way I did. I may even be assigned to write the draft of the user’s manual and other documentation. So it helps with my writing and editing skills. Here’s another systemic view. I keep this mind when I’m developing. It also helps me become a little better organized as I go along.
The topic discussed at 3:50 is exactly why AI bots like ChatGPT won't be replacing Software Developers any time soon. All these bots can do is take in a description and write code that vaguely matches what the description is. It's no more useful than using Google translate to write a book in another language. It might be "correct" in a small context but won't be fully designed to be approachable for humans or could have strange and unintended behavior that the descriptor never expected. In the end, it's still the human that has to know and understand the design systems really well to even create a description that would be half decent for real use at all.
Thank you very much! I was happy I am doing most of your advices. I felt bad when you said “you did this” but it is a “good” bad feeling I guess I did it couple of times, I won’t do it again Thanks
I just started coding a year ago and somehow landed a job in an awesome company and I felt so soo off in the beginning, because I wasn’t fast enough, I still don’t know what they are talking about in technical meetings and I made a lot of mistakes. The thing is, nothing of that mattered. I asked people frequently for their opinion on my ideas of problem solving in order to improve. And funny enough, my senior colleagues are just the same. I find it funny how when we pair program my boss is always like: „what… I don’t understand what it does here“ - same, man!
20+ years as a programmer. I still feel stupid sometimes. Some people are just so smart and fast that you just smile and nod and hope they don't find out ;)
Fast typing! Excellent! All the better for writing out nice comments in the code to explain why the business wants it to act in such & such way and to explain why this rarely used programming technique is particularly suited for just the problem at hand!
I like small teams, where each person has its own expertise at something. I feel like me and the code are one thing. Other guys just say how the code needs to be changed and the next moment the fix is already packaged and waiting for validation and deployment. That is covered with UT, tested and verified on my machine, code style maintained, clear commits are properly organized and pushed where they needed to be, appropriate branches created/merged if needed, change log, versions and tags updated. In other words I keep everything organized and keep it clear for others. If someone else is doing changes to the code I just tell them what branch to use and let me know when everything they wanted is committed. Others don't need to know much about git as long as I am in the team. Similar interactions we have with domain experts. We jump on a call and our complementary expertise finds the root cause and resolves the issue. Sometimes he needs to check/verify/provide something 600000 times, so he explains and I make a shell script from his words, or use one grep command with regex, or few vim shortcuts and the problem is solved. They want something and I know exactly how to do it super fast.
My working metode is. 1: make the test so it assert the expected outcome. 2: make the code solve the problem. 3: reveiw the code clean and refactore it. The first step forces you to understand the buiness/problem first. Second is to get it to work. 3ed when it works and the test parse then look at cleaning it up and look at performance
There's another reason you can really help the business understand their problems: you can give them the computer's perspective. It's easy for people to gloss over situations that rarely happen but, when you're coding, those issues are far easier to see. "If such & such then DoThis() else... ummm.... uhoh."
Have only one objection. These are not limited to junior devs. Realizing that I am in or about to fall in one of these traps is the times in my career that feel like I am an expert for a short while. Never relax on these issues or I might fall into it again. Great video👍 talking from 20+ experience.
The issue with number 2 is when I notice an issue and let business know about the issue they come back at me with you figure it out which is great giving me all creative freedom to mess someone’s financial life up. What is exactly the business job? Isn’t it to come up with requirements?
I would add a few points to the excellent summary presented in this video, if I may. One, learn the difference between software architecture and software plumbing. The former should facilitate minimal, well crafted, scalable and expandable systems, and creation of software capital. The latter may entail a substantial time investment in learning the incompatibilities of various third party libraries with one another, and can lead to an assembly of modules glued together with some code, which should fit the requirements, but is sitting on top of hidden 'features', side-effects, limitations, and potential future scaling and versioning problems. Two, this one is elementary: avoid copy-pasting either someone else's or your own code to many different places in the system. It can lead to endless problems later and a lot of wasted time. Create reusable components instead. Three, rid yourself of any 'it works on my PC' syndromes. Your software must perform well on all the prescribed customer devices and platforms which may have a number of differences one from another. Do not trust your working code. Keep looking for missed corner cases and optimizations. Four, avoid cultivating the self-image of being an X language developer. You are a computer programmer, a problem solver and that entails about 70% thinking and planning and the rest coding. Languages and libraries are simply tools of the trade.
That point about writing code faster makes you better at software development. One of my biggest pet peeves with online training videos on RUclips is the idea of, "this is how you can super quicky type fast" or "learn these shortcuts to be faster at coding" or the concept of a coding Ninja because your "so fast" and never touch your mouse! Mouse is bad for programmers, just keyboard. Hate it so much. There is nothing inherently wrong with any of it, but it fails to realize the true a nature of software development. I'm a senior developer for a large enterprise company and I would be lost without my scroll wheel :). This is the best advice I can give to a junior, slow down, breath. Think about the problem. Take your time. Understand what your goal is and get there with as little typing as possible.
As a developer, you know you're supposed to look up what they do on your own. 😄🤣 Dont let anyone know you don't know what they are hushhhhhhh its a secret. 🔔 SHAME! SHAME ! SHAME ! 🔔
While I trust your expertise in many things, I cannot agree in the part about "I could do a better job, but my boss won't let me!". Obviously, you are talking from your perspective, from your experience. And while, in some cases, I had a similar experience as you... in some other cases, it was the opposite. In one company, the software created, was for the company itself, so ... they wanted quality code, of course. That meant, better code, less time invested in the long run, and less bugs along the way. BUT, and this is a huge one, in another company, they wanted us to patch things up quickly for the client, with less quality code. To the point that I was able to see an issue that I had worked on (I had the right solution, but could take about 3-4h to code/test/etc) in about 1h30m, by patching it up fast (the system was a bit of a nightmare, no repos, dealing with cache systems, publishing directly to production, ... you name it!), being fixed again, and again by EVERY SINGLE MEMBER of the dev department. Total estimated time for all the patches? about 9h of work. But ... what happened, well ... every single hour was billed to the client, so ... "it was good for business". The other devs and me, we did not paid attention to what management was telling us, in regard of the bad quality code (we did paid attention to anything else, obviously), and we started doing high quality code. And we were able to 'good-code' us out of a job. YES, we were all fired when all the sites and services were up to spec, and jobs taken back to India (were they were originally taken from). Believe it or not, the spaghetti code on those sites was HORRENDOUS! To the point of ... low score on google speed pages, long and difficult to update sites, redundant code, etc. To put it mildly, there was a horrifying "dynamic" menu made with about 100 lines of code, where the dynamic part didn't work, so they left it there, and hardcoded every part of it. It took me a couple of hours, to remove all that, and in 15 lines of code, the menu would scan the objects tree(an object could be a whole page, a section, or a button, etc.), filtering the pages, and checking the value of the "menu" property, and if it wasn't disabled, it would add the object to the top menu, or the footer, or both. It was faster, cleaner than the original, and when I let marketing know that they could use the menu dropdown to set up their menus, they replied ... "But ... that had never worked before!" ... well, now it works! So that was what we were dealing with. PS: Our bosses also got sacked. Departement boss, team leader, etc. It was cheaper to move jobs back, after we fixed all the sites. 🤷♂
Do you have any other tips for developers at the start of their career? DROP THEM IN THE COMMENTS BELOW! 👇
Don't try to "beat" anyone in speed etc. and try to focus on collaboration instead, or you will generate resentment from the person you "beat", you really don't want.
Don't be crazy possessive about your code. Your "perfect" code could be changed by someone else and getting all pissed off about it is incredibly annoying to everyone else.
Be very thoughtful and caring when pointing out someone else's mistakes. Point out that you have also made the same mistakes in the past.
Proposing innovations and improvements could land you into conflict with the person who was responsible for the code or the process you suggested could be improved, because he or she didn't think about it first. Make sure you compliment that person's efforts first.
Growing from novice to a better developer is not about reading a lot of beginners' books, watching a lot of tutorials or going to a lot of courses; it's a slow process that imply **doing*: Make a lot of programs, say, *solve** a lot of problems, and **make** a lot of mistakes. It could seem overwhelming at first, but it is an exponential grow. Not only solve the problems you have **ordered** to solve: Find similar, simpler problems and solve them. The insight so obtained is the oil that will make your solving machine go smoother and increasingly powerful.
I have a saying in my shop: "The user doesn't know what they want until you show them what they asked for!" This is an essential part of the requirements gathering process. By building an early/quick prototype version of a system that represents your understanding of the user's stated needs, you establish a 'common ground' or 'context' from which to grow the real understanding of the requirements. And as a bonus, the user feels more engaged in the process as well.
I want to reinforce: if you say you are done with the task, but when asked if you tested, your answer is no, then you are not done.
You are not even half done. You barely started.
Don't be afraid to ask colleagues for help.
More often than not, someone you work with knows as much or more than you do, and they are as or more worthy a resource as a bookshelf, or a Google reference. Even senior-level people ask questions and yes, sometimes they ask dumb ones. Outside forces can affect someone's thinking: C19 human malware, family matters, and so on. And don't just ask for coding help, all the topics are valid: design, user desire, business rules, etc. Ask for help when you need it. Ask for context when you need it. I would suggest taking time to research the problem you need help with first. It does get embarrassing to ask a question only to answer it yourself the moment you hit send--but senior people have been through that. Still, it happens.
I'm not going to deep dive on the, "what if I ask too many questions, will I get fired?" route. The truth is you'll always be evaluated. Generally when you're hired, the company has a good idea of what you're capable of--also why most companies have a 3 month probation. Learning the company's software for example will likely be an initial role, and sometimes asking questions is expected, and not asking questions might be the wrong thing to do.
*Timestamp*
1:50 1. "SW Dev is all about Coding"
3:50 2. "If only the Business would get the requirements right!"
7:08 3. "Speed is all that matters!"
9:22 4. "My Job is to Code, Not to Understand the Problem Domain!"
11:05 5. "I can't ask for Help! It shows that I don't know enough"
12:18 6. "Software Architecture is for the Experts!"
14:00 7. "Testing is someone else's job!"
15:20 8. "I would like to do a better job, but my boss won't let me!"
Thank you for time saving🙏
Before watching the video I thought those were the solutions, a little harsh but still, not the problems
This is a bit of a weird video to timestamp, just watch the whole thing lol.
@@imadetheuniverse4fun it's more for review purpose tbh
Thank you sir. you are doing gods work.
This video was humbling. I've been writing code professionally for 15 years and I'm guilty of some of these mistakes.
better and better on a daily base, lifelong apprentice ! ;)=)
Kind of similar here, writing software for some years, and unfortunately in an environment that is not quite state of the art concerning tools and methods. So there is a lot to improve (at least superiors are open for these).
Continuous Improvement, both on an individual and on the company's side...
WE All Are Hey!
You realise you've grown up when you realise you made those mistakes, and you try not to make them again, knowing the consequences. Eventually, all of those mistakes were made, and you can finally enter adulthood.
So that's where all those "Junior dev with 15+ years of experience" are coming from? 🤣
Just kidding of course, don't take it personally ;p
I've found that changing the question is a great way to find a solution that works. Never start by asking a customer what they are looking for, start with, could you describe the problem, or show me what problem you are running into. Not only will they willingly give you more information, everyone likes to complain, but you might be able to fix it in a way that gives them more value for less work. If not you can always follow up with, "and what do you envision the solution looking like." if you are talking to management, or "what can we do to fix it for you." if you are talking to a lower-level employee.
Oh, a development channel that doesn't make me cringe. I got goosebumps ... Keep up the great work
Yeah he earned a sub just because I have struggled with getting my foot in the door of a development job and I feel like his wisdom will be invaluable in building if nothing else my self confidence to make more so I can flesh out a better portfolio.
* cough * The Tech Lead * cough *
@@J90JAM that guy is trash
@@techtutorvideos exactly.
“Smart people ask questions, dumb people think they have all the answers.” Spot on! I was brought up on, and have successfully lived by the thesis “He knows the most who knows he knows nothing.” It’s where we all start and what enables us to learn.
I've only watched a few of your videos, but I'm liking your content so far...
In this video, for example, you have covered many topics that I have been preaching for the past decade, and It is heartening to finally find somebody else on the same wavelength. I have been working in the manufacturing business systems field for many years, and have had many of the experiences you described, and my real frustration is the fact that most organisations don't want to even acknowledge these issues, let alone change to a new way of thinking and working on I.T. projects.
My company takes the much more modern approach to developing software - the main being that we do NOT think of ourselves as software developers - we are actually "Business Problem Solvers" - and computer systems are just the TOOL that we use to solve those problems. If you concentrate on actually solving the problem and improving the business, there are very different priorities.
We find that if we stick to some simple principles (inspired by agile software development principles, which in turn is inspired by Lean manufacturing and Goldratt's ToC):
1. "Capabilities", not "Requirements"
Concentrate on the overall "Capabilities" that the USERS need to solve the PROBLEMS - let the developers figure out the best way to deliver that capability, rather than insisting the business describe the requirement in real detail. i.e."I need to be able to take photos on a building site and automatically put them into a report template for our client"
2. Small batch sizes - develop and release capabilities in short quick chunks
3. Short feedback loops - get the developers talking to Users directly, release, test and refine a capability in as short a time as possible - preferably in hours, not days or weeks
And in general, for solving business problems, the answer/system generally needs to the same simple things:
1. Make work visible
2. Be able to see any Business Operational problems quickly (and to "swarm the problem" as the famous saying goes)
3. Create communication "Protocols" between employees and teams - give the conversations common language, structure and methodology - reduces errors, confusion and waste.
I think we sometimes forget that this whole industry used to be called "Information Technology" - as a society, we've concentrated so much on the Technology part, we forgotten that the actual reason that all this exists is to improve how we use and transmit INFORMATION - and this couldn't be more important than within a complex business.
As software developers, we have the potential to MASSIVELY increase productivity in this country, if only manufacturing and business would adopt some of these simple approaches to using technology in their operations. They usually have a board of directors that includes representatives from HR, Health and Safety, Marketing, Sales, Manufacturing.... I have yet to meet a medium sized manufacturing business in this country that has a technology expert on their board - it's simply viewed as a "Service" like payroll or the canteen, whereas in this day and age - a real business strategy IS a technology strategy.
My company has set out on a mission to change this situation by developing software that solves real business problems quickly and continuously, and finally get I.T. professionals "A Seat at the Table".
James Hathaway - Technical Director at SigmaDX Ltd.
Resources that insipired this post:
Eli Goldratt - his entire Theory of Constraints master work.
"The Phoenix Project" - by Gene Kim, Kevin Behr and George Spafford
"A Seat at the Table" - Mark Schwartz
"Black Box Thinking" - Matthew Syed (Better to fail fast and learn than to be paralysed by indecision)
"Lean Startup" - by Eric Reis
"Toyota Kata" - by Mike Rather
on the topic of Speed is all that matters" i always counter with "first you get good, then you get fast"
From the US Navy Seals: "Slow is smooth. Smooth is fast."
Going fast in the wrong direction will crash you into a wall. Try to know where you are going and do not paint yourself into a corner.
If you want to help the channel, share the video on the social networks. This man is giving you all the knowledge he has on a silver plate! Thank you very much for the video!
Thank you 😊
This channel is underrated!
Thanks for sharing that much of good content.
Coding in itself is "easy", thinking, designing, debugging, launching a software is at an another level.
Sadly, they keep stacking up the expected requirements for a job too. I think it would be better if the bosses would hire programmers from a few different experience levels and then a lesser programmer could actually get experience and the higher level programmers could have someone to take care of some of the grunt work.
I have a Master of Science in Software Engineering and I honestly wish I could go back and replace my coursework with nothing but the videos on this channel since it honestly would have had a more powerful impact than the standard curriculum.
haha so true ;-)
I hope you feel you got your money's worth from school. It's lots of sacrifice to get a masters. I'm going through mine now. I would probably feel so jaded if I thought it was a waste.
@@kb3khs You don't go to college to learn new things; information is freely available to anyone and a teacher is only there for support, not to gatekeep knowledge. You go to school for a piece of paper that vouches for your critical thinking skills and lets an algorithm that processes resumes sort yours into the "review" pile instead of the "reject" pile.
"There is a professional duty of care that we are all responsible for." --Couldn't agree more. Loved the "clean as you go" example.
Thanks
With any career, it is important to be proactive. Don’t just sit there and only do just enough of what’s being told to do. Activate your mind, and always be curious at everything.
Yes, it is obvious that new people are looking for guidance, but at some point we all have to take ownership of our own work.
Being proactive is only possible when the culture is right, I'm currently working at a company where it is absolutely not appreciated. I've been yelled at multiple times for simply notifying the team about bugs.
@@unrealcyberfly , my advice would be to proactively try to fix the bug. Then, present to your boss the fix. In my experience, bosses don’t like complainers, just doers. It will put you in a great advantage as a dependable member of the team.
@Peter Tran In this case the bug comes from a colleague's output. I've cleaned up their mess before, no more! Colleague is the boss' sweetheart and hides "behind a lack of knowledge". --- I just needed a place to rant, thanks for listing.
@@unrealcyberfly Goodness, that's the worst
This is good stuff. The business will never get the requirements right alone. A good engineer will work with the business to define the problem and the potential solutions. Writing code, incrementally, allows us to test with the business the best solutions. We are not two teams. Keep up the good works, subscribed!
I used to work with computational physics (fluid dynamics), and a recurring problem I found in the community was that they were very focused on marginal improvements in speed or accuracy, but not as much on the physics - for example, always running against simple test cases or making unrealistic modelling assumptions. Also, not very much focus on UX or documentation and making their tools accessible to a wider audience.
I didn't firmly grasp the concept of the finding solutions to the problem until my senior dev made me solve a problem without writing a single line of code. Basically using UML diagrams and logic to think through what was actually going on, it was a very useful exercise. Side note, I can't wait to get my copy of the continuous delivery book!
I like drawing pictures to visualise problems, not necessarily UML, but sometimes. I hope you enjoy the book 😎
Awesome, sharp and clearly spoken. This is what a software craftsman distinguishes from a developer.
I think actively evolving communication skills is vital.
Its all about language, text, discussion and understanding the requirements and problems.
A precise, meaningful and structured communication is so important.
As a CS student, I found your points to be very enlightening and useful. Many thanks !!
Sigh, true 😉
Glad it was helpful!
@Xiaoran Meng Just to add to what you said: The number of years someone has been a developer may be an indicator, but is certainly not a true measure of seniority. I have seen people who had worked 25+ years as developers, and still could not design anything non-trivial by themselves. Conversely, others needed less than a year out of university to demonstrate true talent. Remember: Having done the same thing for 30 years without constant learning, is not the same as having 30 years of experience. Instead it means "I have learned during the first five years and then stopped progressing".
CS stud here too. Thanks for the vid!
8:03 Please also mention that using many many libraries that came from nowhere does not mean "writing less code". Once a dependency gets added in any form, WE are responsible for maintaining it ir at least upgrading it in the future.
BTW, the contents are good as always. Keep up the great work. Thanks!
8:00 about the fast typing: personally, I gain greater insight into the code by simply attempting a solution and then improving on it, rather than by, say, pseudocoding and trying to get at the answer by non-coding means. It's sometimes hard to oversee the nature of the problem without actually looking at some code that forms part of the solution, even if it's a suboptimal solution. I agree with most of what you say here but for me, working fast and typing fast are integral to my ability to focus and concentrate
Awesome content, thanks. IMHO, you can strike "junior" because some of these mistakes (especially the last) I can see long time professionals do as well (who might think of themselves as seniors)
Yes, sadly true.
Being "Senior" or "Junior" has little to do with how long you have been doing the job. Perspective is much, much more important.
Hi! Love your content! Could I suggest you add time stamps to the description to add book marks on the RUclips videos? For instance: 0:00 - intro, 1:48 - mistake 1: SW dev is all about coding, 3:47 - mistake 2: If only the business would get the requirements right etc... This is helpful so that viewers can jump to a specific point quickly in your video especially in a video with a list of items. I love the refactoring series. It's actually quite satisfying trying to make code cleaner and concise.
0:00 - Intro
1:40 - SW Dev is all about coding
3:47 - If only the business would get the requirements right
7:08 - Speed is all that matters
9:21 - My job is to code not understand the problem domain
11:03 - I can't ask for help, it shows I don't know enough
12:17 - Software architecture is for experts
13:58 - Testing is someone else's job
15:18 - I would do a better job but my boss won't let me
16:42 - summary
Thanks for the suggestion
@@ContinuousDelivery no worries! Please see the above message for the complete time-stamps for this video. I believe you can edit the description after posting and it will update the timeline 👌
Thank you for this list. It's branded as for juniors but lots of seniors can learn from it as well, including myself.
14:12 _"If not, then you're dangerous, and need to take a step away from the keyboard."_ HAHAHA!
😉
@@ContinuousDelivery Made me subscribe :D
Randomly found this channel. Found out that, on many points, I tend to think a lot like you, despite being in this business and in the same company for roughly 7 years, meaning that I lack a lot of experience. I love this and will most likely spread this among the colleagues, some of them definitely need to hear this =) Thank you for this.
All your points are 100 % spot on. Believing the client will provide a substantial and useable blue print for the new application is particularly bad. You have to take time to understand their business and take time to come up with the best solutions, which might differ significantly from what they think they need.
4:23 I don't fully agree about the business. I wouldn't say, it's the job of the programmer or the business alone, but the programmer has to find out by talking to the customers while making suggestions and clarifying, what would be possible. Else half of the code will have to be rewritten because the customer doesn't like it.
To extend the carpenter metaphor, it's common to see younger people arguing about what amounts to whether cutting the wood or fastening it together is more important, when any experienced professional knows the important thing - and the thing you'll spend the most time doing - is MEASURING the wood. In software development, people will argue incessantly about whether it's more important to design the code or to write the code, when the experienced professional knows that while both of those are critical... you'd better spend most of your time TESTING the code.
Yes, I should have extended the metaphor 👍😁
An Addition to the "ask for help" advice:
Ask different people the same question, even if you think you understood it well after the first answer. You will most likely get to learn another point of view on that same topic and understand it even better. Same applies for online research, always have a look at different sources.
Also dont worry about wasting peoples time, you might even do them an indirect favor! Explaining stuff is imo one of the best theory practices one can have, even if its just refreshing already familiar topics.
True, different angles will give you better overall understanding of an issue, since you're covering more ground.
I started programming in 1970. I think these suggestions aren't just for beginners. This is the best you tube presentation on programming I have seen.
I really dont know how until know I find this channel.... I have been looking at videos about programming since about a year now, trying to learn by myself and doing some minor projects, and until now I find this gem.... Thank you alot for all the info and all the information!! hope your channel gets as much as you which for it!
These are suprisingly good advices to any professionals, not just developers
Yea, I'm a test automation engineer and a lot of things mentioned in this vid are applicable to software testing/test automation. I'm gonna share this with my co-workers :)
just a note about knowing the problem domain, I do optimize, debug and improve lot of system without really knowing the domain at all, because I concentrate first on refactoring/cleaning the support material, libs etc.
So many code are badly written, a lot of time optimization is ENORMOUS by reworking the inner algorithm (like changing a bubble sort to a quick sort improvement) one of my last dramatic change was rewritting a SQL query that was written by an Oracle DBA, with all kind of obscure command and attribute proprietary to Oracle, I just clean it back to the originale intents, write the proper query, with trigger and precalculated value so the 12 hours report dropped down to 15min ... without any specialized oracle commands, my query work on any SGBD with minimal syntax adjustment!
Combine this to the KISS principle, and optimization and easy maintenance is usually the results.
But I guess you need to be a bit more experienced before attempting that, too many employer got burn by eager junior to 'rewrite stuff' .. but if we didn't reinvent the wheel, we'd still be on wood wheel...
With experience you start 'smelling' the poor code that would gain a lot by refactoring/redesigning...
So many good points to think over for me as a junior dev. I alway find it difficult to ask questions, not because I don't know the questions to ask but mostly because to not be seen as annoying. Combining this to the point of taking the ownership, I will try not to feel intimidated for asking the questions.
If you don't ask questions to get a better idea of what needs to be done, you will definitely feel intimidated later when things go wrong
I discovered this channel only a few weeks ago, and I am stunned by the quality of the content. In my opinion, all the videos are must watch for any engineer that cares about their work regardless of seniority. Thank you for making such great content available to everyone Dave.
11:39
Beautifully stated, and a great piece of advice.
About your last topic, addressing issues with management it is relatively a lot easier for a someone senior or someone with other options.
People don't choose to not write tests or not to estimate right. These things could just so happen to be there.
This is a lot more sensible topic, and I don't believe standing up works often, specially for Juniors and smaller companies.
Of course this is often used as an excuse to not take ownership of a task, but lots of places do have a crappy work environment and won't let you do a better job indeed.
The man seems to be so competent and his speaking is so credible that I adore to listen to him even though I have nothing to do with IT 😂
Dafuq ? lol I kinda like people who arent in IT taking an interest in what we do.
CHEERS MATE !
Watching this video feel so great that I can watch it again whenever I need to and it will always sound reasonable to me. Kudos Dave. 👍👏
Glad you enjoyed it!
8:00 I love that you would say that, as when I think fast and am awake I type fast and make big changes on the fly all working, but when my brain is chilling I'm gonna have a really long time typing one word, like a cold engine unable to warm up.
The one I often see is following oft touted rules like don’t-repeat-yourself dogmatically, rather than pragmatically. The pros and cons of following any given rule should be evaluated when applied, because sometimes the extra complexity to the system isn’t worth the stated benefits
Agreed, to every DRY sycophant, I offer AHA. The rules are there to handle things generally, doesn't mean they cover every case. While I'm ranting, less lines != better. I hate it when people play code golf with production code that's maintained by a team. Write for the team. Final rule, and this is one I find to almost always be true, premature optimization is a quick path to hell.
@@TheMrVogue What's AHA?
This (all of this) is great advice. Not only for junior devs; this is what every day at the office should start with, or have these printed on a wall.
Thanks 😎
This feels more like a critique of development teams and or the management rather than junior devs.
yeah most of this is just bad habits you get from working with bad people
this video is a great insight, I'm guilty of writing before thinking and later having to refactor it.
God, I love your channel :) Seeing a seasoned veteran continue to work and engage in my industry gives me so much hope for my future
Thanks 😁
Excellent, excellent way of saying what the value of developers is in context of "the business not getting the requirements right". It shifted my perspective on things, and I will be sending this video to friends of mine just for that segment.
Thanks for the feedback - good to know the video has made a difference!
Recently discovered your channel and I'm very impressed with the advice. I'm a hobbyist dev looking to go pro as a full stack web dev. I never really used to write tests but have recently tried out a basic tdd approach and it was really interesting and helped me think about the problems I was trying to solve.
What's a basic TDD approach
Why are there only 73,000 subscribers as of today. This is the best youtube channel in IT, ever, period.
Great video, thank you! I'm two months into my first software engineering role and luckily haven't fallen into most of these traps... a few might be borderline though hah
😇😉
I felt the need to give you a standing ovation for some of those points and the way you said them, especially the second one!
Thank you! I hope you found it thought-provoking!
At the age of 57, I'm learning software development. I must concede that your videos give such a broad overview of software development, that it makes it always more interesting. Great !
That's great to hear! Good luck with your learning. I hope my videos help!
@@ContinuousDelivery : Extremely ! I've quoted you on LinkedIn and advised my fellow colleagues to enjoy your videos :-)
You just changed the foundation of my beliefs on requirements... Thanks! My job is a lot harder than I thought!
Yes, it is, but more fun as a result 😁😎
I am a new dev in my first year and this is the best video! I've seen many of these mistakes made by myself and others.
The last one is sometimes true though. One project I worked on I told them it's a 12 month project. They gave us 4 months and pocket change. Every meeting when they asked about progress I told them, we will not meet the deadline, we need at least 6 months extra runway. Naturally they would argue about the schedule not aligning with business interests. I told them this is a foundational system and surely that is more important than whether the release window is ideal - if so concerned, then push release back to next year and we can use the additional time to improve the system further... Never budging...
Wow! So much value in a 20 min video! I would need to re watch it again and again to truly understand the ideas completely. Thanks a lot for sharing your experience!
The part about "If only the business could get the requirements right," being wrong is something I learned early on in doing freelance 3D animation. It was my job to know more about animation than them. If they recommended I make something that I knew would look bad, make text hard to read, not convey the correct information, etc. it was _my job_ to clearly (and politely) convey why it wouldn't turn out how they think it would, and come up with a better solution that would reach their desired outcome.
Examples:
Client says it's too dark and tells me to make the lights brighter; I intuit that they're saying this because the text is hard to read and instead make the background darker to make the text stand out; problem solved.
Client says they want the camera to move faster because they don't want long shots of nothing; I realize this is probably because it's early on in the project and we haven't added the text the viewer will need to read yet; I add in the text without adjusting camera speed and the client thanks me for speeding up that shot.
The client always gets the final say, but it's your job as the animator/programmer to translate what they _say_ into what they _want_
I can partially agree with this. Especially the statement that it's our job as developers to help the client express what they want in such a way that we can then implement their idea. However, I've run into scenarios where the 'specification' of what the product was supposed to do kept constantly changing, as it wasn't stated clearly enough. On the long term, this meant that there were cases where days/weeks of work were effectively flushed down the drain. Sometimes, the expression "If only the business could get the requirements right" does apply, even if mostly in the context of "then we would be able to deliver what they want in the time-frame we agreed on".
@@SuperPranx Oh absolutely. I've run into similar situations to you where I've been 90% done with an animation, confirmed that there wouldn't be any more changes with X, Y, & Z, and then around 98% had the client want changes to things that have been "locked," for months and required dozens of times more work that late in the project than they would have otherwise.
Actually worked on a freelance programming project like this a couple weeks ago; specifications set in stone, finished it up, then the specifications changed. Super frustrating.
I think the important thing to note is to not immediately assume it's the client's fault, but instead work with them as much as possible to reach a desired conclusion.
@@ZachHixsonTutorials Yes, I believe we understand each other :)
And yes, it's not about blaming the client. It's more of a longing for that specification that is perfectly defined and doesn't change. A developer can dream... :)
He is absolutely correct about these issues. Someone needs to the employers this as from most of my experience employers are the ones that push a lot of these problems. You can see these examples in job descriptions and if you ever worked in the industry for awhile you would notice they tell you today but expected it to be done last month.
"We shouldn't be asking other people permission to do a decent job." Nice one!, I'll remember that forever.
Great channel and great video. The beauty is that the narrator is actually talking in terms of principles - much of what he describes can actually be applied across the wider business.
Thank You! Glad you enjoyed it!
Love this. As somebody that has been doing this 25+ years, this is pure gold.
This is kind of what is called "staying in the problem-space before going to the solution-space". Focus on the problem, the underlying assumptions, the whom and why, not the what or how.
One of the biggest problems with us programmers is that we tend to jump directly to the solution-space. Some business person starts talking about a problem and 15 seconds later our brains have stopped listening to the problem and is instead filled with arrows, boxes, patterns and whatever technology we know. Five minutes later we don't even remember what the problem was, just that we get to write a bunch of code using nodejs, k8s, docker and NoSQL (because I don't have NoSQL on my resumé yet). What if the correct solution is to remove a feature, delete 10,000 lines of code and add a new step to an existing process/feature?
Code is not an asset. Every line of code is a cost, a liability. It has to be built, tested, maintained, deployed, configured and operated. Programmers and code do not exist for the sake of their own existence even if we like to believe that we are. We are not getting paid to do our hobby, sitting in a corner with our headphones on, listening to "programmer focus synthwave mixes".
Sorry.
💯😎
This was extremely reassuring for me as a senior dev.
Thank you for making this video. I'm making a career change into web development and these are helpful points. Fortunately, I've always been a very curious person and love learning things and asking questions. I'm hoping that will help me here.
Have a good one!
First video I've seen from CD and subscribed at the end. I'm brand new to software dev but not new to the cybersecurity industry or general life/work principles and this video was spot on. 👌
Love the chef analogy at 15:45
Invaluable advice. I did nearly all of those mistakes in the beginning :D
I worked at a place where the clients often did not know what they wanted and when they thought they knew what they wanted it was sometimes based on false notions. I had a talent for explaining things in a simple manner that non-technical folk could follow and find out what they really needed even when they wanted something that made no sense. I am not sure if I should mention the last part of that to potential employers though. They may not like the idea of employees second guessing their clients' wishes.
Than you for sharing your invaluable knowledge and experience!
Love your videos, titles sound like the titles from thousands of other clickbiat videos, but you actually give deep thoughtful and instructional answers/solutions!
3:05 I started to write software, which I actually use, so I don't think about if I would like to use this software, but I try to make it as comfortable to use for me as possible.
Eeeeh this can be broadly applied outside of software development. Great stuff
Great video, such important topics that are not discussed enough. Thank you!
7:42 I almost don't type, when programming. I can type pretty fast, I guess, but also not too that fast.
Most of the time, I have to rearrange code, which already exists, anyway.
So efficiently using copy/paste is probably more important than fast typing.
Or putting code, which you often reuse into a function, so you don't have to write/copy that much.
Excellent advice. Gets better as it goes on.
Great video!
I am guilty of some of these.
Really humbled me a few times.
I used to ask a lot of questions then around my 3rd or 4th year an engineer said he always knew how little people know by the questions they ask(which is true) but so what?...
I am so over the ego BS, I just want to write robust, clean, solid software.
This is an outstanding video even by your already high standards. I'm glad I've got something to link junior people to when I hear this stuff.
I have one I learned early on:
“It isn’t my job to explain or teach.”
Is this mad? You bet it is. Eventually I will have to teach the team why I developed the way I did. I may even be assigned to write the draft of the user’s manual and other documentation. So it helps with my writing and editing skills. Here’s another systemic view.
I keep this mind when I’m developing. It also helps me become a little better organized as I go along.
Thank you for your wisdom. What a treat. It's amazing how much of what you are saying applies to life in general.
Glad it was helpful!
The topic discussed at 3:50 is exactly why AI bots like ChatGPT won't be replacing Software Developers any time soon. All these bots can do is take in a description and write code that vaguely matches what the description is. It's no more useful than using Google translate to write a book in another language. It might be "correct" in a small context but won't be fully designed to be approachable for humans or could have strange and unintended behavior that the descriptor never expected. In the end, it's still the human that has to know and understand the design systems really well to even create a description that would be half decent for real use at all.
Hi Dave, what do you think about the FANG companies' way to screen and test devs? (whiteboards, tons of Leetcode etc..)
Great video! Thank you so much. Hope that you continue making videos!
I’m so glad I found this video!
Thank you very much! I was happy I am doing most of your advices.
I felt bad when you said “you did this” but it is a “good” bad feeling
I guess I did it couple of times, I won’t do it again
Thanks
To be fair, we have all done this at some point, so don't feel bad.
I just started coding a year ago and somehow landed a job in an awesome company and I felt so soo off in the beginning, because I wasn’t fast enough, I still don’t know what they are talking about in technical meetings and I made a lot of mistakes. The thing is, nothing of that mattered. I asked people frequently for their opinion on my ideas of problem solving in order to improve.
And funny enough, my senior colleagues are just the same. I find it funny how when we pair program my boss is always like: „what… I don’t understand what it does here“ - same, man!
20+ years as a programmer. I still feel stupid sometimes. Some people are just so smart and fast that you just smile and nod and hope they don't find out ;)
Very pertinent
Especially, the last one
I play typeracer in my code everyday too. Later I have like ten times the work when sorting and single out changes for my commits :-/
🤔
@@ContinuousDelivery ADHD for ya :-/ ...Or maybe just the wrong setting on the coffee maschiene
Fast typing! Excellent! All the better for writing out nice comments in the code to explain why the business wants it to act in such & such way and to explain why this rarely used programming technique is particularly suited for just the problem at hand!
I like small teams, where each person has its own expertise at something. I feel like me and the code are one thing. Other guys just say how the code needs to be changed and the next moment the fix is already packaged and waiting for validation and deployment. That is covered with UT, tested and verified on my machine, code style maintained, clear commits are properly organized and pushed where they needed to be, appropriate branches created/merged if needed, change log, versions and tags updated. In other words I keep everything organized and keep it clear for others. If someone else is doing changes to the code I just tell them what branch to use and let me know when everything they wanted is committed. Others don't need to know much about git as long as I am in the team. Similar interactions we have with domain experts. We jump on a call and our complementary expertise finds the root cause and resolves the issue. Sometimes he needs to check/verify/provide something 600000 times, so he explains and I make a shell script from his words, or use one grep command with regex, or few vim shortcuts and the problem is solved. They want something and I know exactly how to do it super fast.
My working metode is.
1: make the test so it assert the expected outcome.
2: make the code solve the problem.
3: reveiw the code clean and refactore it.
The first step forces you to understand the buiness/problem
first.
Second is to get it to work.
3ed when it works and the test parse then look at cleaning it up and look at performance
There's another reason you can really help the business understand their problems: you can give them the computer's perspective. It's easy for people to gloss over situations that rarely happen but, when you're coding, those issues are far easier to see. "If such & such then DoThis() else... ummm.... uhoh."
That's a familiar feeling. Nothing like writing code - especially in very explicit languages - to find your edge cases for you
This is the must for everyone starting a software engineering careers and repeat the watching for couples years to remind self..
Great information! Thank you so much for sharing.
Have only one objection. These are not limited to junior devs. Realizing that I am in or about to fall in one of these traps is the times in my career that feel like I am an expert for a short while. Never relax on these issues or I might fall into it again. Great video👍 talking from 20+ experience.
Thanks 😎
The issue with number 2 is when I notice an issue and let business know about the issue they come back at me with you figure it out which is great giving me all creative freedom to mess someone’s financial life up. What is exactly the business job? Isn’t it to come up with requirements?
I would add a few points to the excellent summary presented in this video, if I may.
One, learn the difference between software architecture and software plumbing. The former should facilitate minimal, well crafted, scalable and expandable systems, and creation of software capital. The latter may entail a substantial time investment in learning the incompatibilities of various third party libraries with one another, and can lead to an assembly of modules glued together with some code, which should fit the requirements, but is sitting on top of hidden 'features', side-effects, limitations, and potential future scaling and versioning problems.
Two, this one is elementary: avoid copy-pasting either someone else's or your own code to many different places in the system. It can lead to endless problems later and a lot of wasted time. Create reusable components instead.
Three, rid yourself of any 'it works on my PC' syndromes. Your software must perform well on all the prescribed customer devices and platforms which may have a number of differences one from another. Do not trust your working code. Keep looking for missed corner cases and optimizations.
Four, avoid cultivating the self-image of being an X language developer. You are a computer programmer, a problem solver and that entails about 70% thinking and planning and the rest coding. Languages and libraries are simply tools of the trade.
If they suddenly want me to code in Java, I am gone!
That point about writing code faster makes you better at software development. One of my biggest pet peeves with online training videos on RUclips is the idea of, "this is how you can super quicky type fast" or "learn these shortcuts to be faster at coding" or the concept of a coding Ninja because your "so fast" and never touch your mouse! Mouse is bad for programmers, just keyboard. Hate it so much. There is nothing inherently wrong with any of it, but it fails to realize the true a nature of software development. I'm a senior developer for a large enterprise company and I would be lost without my scroll wheel :).
This is the best advice I can give to a junior, slow down, breath. Think about the problem. Take your time. Understand what your goal is and get there with as little typing as possible.
such a good speaker - love this!
Your channel has helped me greatly! Thank you for sharing your knowledge!
I love how he just dumps the sponsors at the beginning of the video without any further explanation of what each of them do.
As a developer, you know you're supposed to look up what they do on your own. 😄🤣
Dont let anyone know you don't know what they are hushhhhhhh its a secret.
🔔 SHAME! SHAME ! SHAME ! 🔔
While I trust your expertise in many things, I cannot agree in the part about "I could do a better job, but my boss won't let me!". Obviously, you are talking from your perspective, from your experience. And while, in some cases, I had a similar experience as you... in some other cases, it was the opposite.
In one company, the software created, was for the company itself, so ... they wanted quality code, of course. That meant, better code, less time invested in the long run, and less bugs along the way.
BUT, and this is a huge one, in another company, they wanted us to patch things up quickly for the client, with less quality code. To the point that I was able to see an issue that I had worked on (I had the right solution, but could take about 3-4h to code/test/etc) in about 1h30m, by patching it up fast (the system was a bit of a nightmare, no repos, dealing with cache systems, publishing directly to production, ... you name it!), being fixed again, and again by EVERY SINGLE MEMBER of the dev department.
Total estimated time for all the patches? about 9h of work. But ... what happened, well ... every single hour was billed to the client, so ... "it was good for business".
The other devs and me, we did not paid attention to what management was telling us, in regard of the bad quality code (we did paid attention to anything else, obviously), and we started doing high quality code. And we were able to 'good-code' us out of a job. YES, we were all fired when all the sites and services were up to spec, and jobs taken back to India (were they were originally taken from).
Believe it or not, the spaghetti code on those sites was HORRENDOUS! To the point of ... low score on google speed pages, long and difficult to update sites, redundant code, etc.
To put it mildly, there was a horrifying "dynamic" menu made with about 100 lines of code, where the dynamic part didn't work, so they left it there, and hardcoded every part of it. It took me a couple of hours, to remove all that, and in 15 lines of code, the menu would scan the objects tree(an object could be a whole page, a section, or a button, etc.), filtering the pages, and checking the value of the "menu" property, and if it wasn't disabled, it would add the object to the top menu, or the footer, or both. It was faster, cleaner than the original, and when I let marketing know that they could use the menu dropdown to set up their menus, they replied ... "But ... that had never worked before!" ... well, now it works!
So that was what we were dealing with.
PS: Our bosses also got sacked. Departement boss, team leader, etc. It was cheaper to move jobs back, after we fixed all the sites. 🤷♂