@@GordonZhu I think it's the perspective shift that, DSA questions are not just for testing your knowledge in DSA, but actually to test your general problem-solving abilities; something that takes longer to cultivate. Also, the way you explained how companies need to filter down candidates made sense; it feels less unfair now.
very useful content as ever, I'm going to send this to a few folks that I know have been struggling with interviews lately. btw: Wish I could get an interview for Evil Corp :(, they're just ignoring my resume
Thank you jcroyoaun! Haha everyone wants to work at Evil Corp. Also, this advice applies to everything, resumes included. Highly recommend asking your your most competent yet harshest friend to tear it apart a few times :)
I guess my GenX generation and my parents (boomer and silent generation) know how to efficiently program. Because we actually developed significant programs on assembly. Doing that forces you to do write, small to the point functions. If you don’t, the program will not get finished as complexity will grind everything to a hold.
I think this is one advantage I have as a self-taught programmer with the sole focus of being self-employed. My goal is generating income or sell and with selling it's better to have well designed stuff that doesn't take such specialized knowledge. I've had to deal with my code later, the process of deploying it, everything, so... I've learned the value of cleaner code, tests, documentation, and GOOD ABSTRACTIONS. Idek how to systematize learning that, but I just try to anticipate as many use cases as possible and then assume that there are even more, I don't understand. Then I can start designing and making tradeoffs knowing how it'll impact usage.
this is exactly how I've been approaching programming. it's not enough to have something that works it should be organized and structured in an intuitive way so your peers don't get lost in your codebase
Agreed. It is an art to write good code without tons of dependencies and unnecessary complexities. Simple interfaces with as simple types as possible is typically the way to go. And of course to structure the code so that each function and class has a clear purpose without side effects. There is also one very important issue which is pretty hard to get right and that is to make code so that you, without too much trouble, can add and expand the functionality. Also preferably while keeping backward compatibility. Predicting the future needs is very hard though. There is two main mistakes you can do here. 1. Not preparing enough for new features. Example: You have a setting where two options are possible, use the feature or not, so you use a logical toggle on/off for that feature. Then you later on realize that you can have two, or more, different variants of this feature and would need some enum input instead. But then you would break backward compatibility by changing it. So you have a problem, often resulting in doing a "new" variant with different signature, which in time leads to a spam of variants of the same function. 2. Preparing too much for the future. It is also easy to overdo the future proofing step and add tons of general options which might be used one day, but not right now. This often results in complicated interfaces where you have to add a lot of input you really are not interested in. Also, the actual extra functionality you will eventually need in the future will typically be different from what you predicted making the situation even worse.
I always try to make sure I understand the code before I check it in. This means I'm slower writing a solution, and it often makes my code slower and bigger, but at the end of the day, I *KNOW* that when I change one part of the program, it's not going to break something in an unrelated part of the project.
From one teacher to another: this misses the point, that everybody either know nothing about or take for granted. The student shall have a working small-step methodology that leads them past making mistakes, and where they can successively improve the quality from 1, via 2, to point 3. Nobody conceives a program out of a vacuum, everybody develops code in dialogue, and when they communicate they improve the solution in direction to point 3 if their methodology is correct.
Crowdstrike overlooked a simple overflow buffer error.. then never tested the rollout of the update on fewer than a global amount of computers.. Obviously number 3 isn't so important.
The third thing you want - after it working, and being fast enough - can be put different ways, you can call it design, other things, but the effect of it is that the cost of making the product do more - adding features or however you want to put it - doesn’t go up too much over time. Modularity may be close to a complete description of this quality. And the key to it is having the right abstractions. (And generally there isn’t one perfect one.) Most developers can use an abstraction and maybe specialize it. A fraction of them can invent/deduce/whatever the right new abstractions that will maintain your modularity over a long period of time and keep the cost of adding new features low.
Levels of Programming Mastery This analysis deconstructs the concept of "levels" in programming proficiency, exploring the nuances and interconnected nature of these stages. **I. The Perceived Levels** The speaker outlines a progression that appears linear at first glance, but later reveals itself to be more multifaceted: 1. **Basic Functionality:** The initial hurdle involves simply getting code to work. This stage is marked by: - **Struggle with syntax and basic concepts:** Beginners grapple with the fundamentals of a programming language. - **Focus on achieving desired output:** The primary goal is to make the code function, even if it's not elegant or efficient. 2. **Performance Optimization:** Once basic functionality is mastered, the focus shifts to efficiency. This stage involves: - **Understanding algorithms and data structures:** Programmers learn to analyze and optimize code for speed and resource usage. - **Prioritizing efficient solutions:** Emphasis is placed on finding the fastest and least resource-intensive solutions. 3. **Elegant Design:** This level, often overlooked, emphasizes clarity and simplicity. It entails: - **Striving for conceptual clarity:** Code is treated as a medium of communication, aiming for readability and understandability. - **Prioritizing maintainability and extensibility:** Solutions are designed to be easily modified and extended in the future. **II. The Interconnected Nature of Mastery** While presented as levels, these stages are intricately interwoven. * **Good Design Fosters Correctness:** Well-structured code is inherently easier to debug and maintain, making it more likely to be correct. * **Clear Understanding Enables Performance:** A deep understanding of the problem and the chosen solution paves the way for effective optimization. * **Solid Foundations Support Complexity:** Mastering basic concepts and design principles is crucial for tackling complex problems, which are essentially collections of simpler ones. **III. The Importance of Foundational Strength** The speaker emphasizes the critical role of mastering the basics: * **Early Struggles Indicate Future Challenges:** Difficulty in achieving clean and simple solutions for basic problems is a red flag, signaling potential difficulties with more complex tasks. * **Simplicity Creates Headspace for Higher-Level Thinking:** Automating and simplifying foundational elements frees up cognitive resources to focus on design and optimization. * **Strong Foundations are Building Blocks:** Just as a skyscraper relies on a sturdy foundation, complex software depends on well-designed and implemented basic components. **IV. Beyond the Levels: A Multidimensional Perspective** Instead of discrete stages, programming mastery can be viewed as a continuous journey of improvement across multiple dimensions: * **Technical Proficiency:** Mastering language syntax, algorithms, and data structures. * **Problem-Solving Skills:** Developing the ability to break down complex problems into smaller, manageable components. * **Design Thinking:** Cultivating a mindset focused on clarity, simplicity, and elegance in code. **V. Key Takeaways** * **The pursuit of elegance in code is as important as functionality and performance.** * **Strong foundational skills are crucial for long-term success in programming.** * **Programming mastery is an ongoing process of improvement across multiple dimensions.** This detailed breakdown provides a comprehensive understanding of the "levels" of programming proficiency, emphasizing the interconnectedness of skills and the importance of continuous learning and refinement.
There are software problems whose best/ideal (or very close to ideal) solutions are already known because of prior work. There are problems that can take an hour to figure out the best solution for. There are those that can take a week or two. There are those that can take longer, like months. There are problems whose best solution have never been identified even after years and years.
I worked in the corporate environment for about 30 years. The biggest failing I have seen is that people program for the 'happy path' and forget about exception handling. When you have code being used across an enterprise by thousands of people and perhaps customers, then the developer has to have the attitude that the code can't fail. It must handle a variety of situations, even unforeseen situations, gracefully. Yes, writing code from an academic perspective is great. However, there is also the reality side that can be overlooked.
In reality there are more levels. You need to document the code, to explain not only what does the function, most important is to explain why it's doing it, what logic requires it, what datatypes enter and what exits. You need to cover well the logging to show the call stack if error occurs and clear error messages and to make clear the source of the log, like in API logging to know who did it, when and what exactly did, how it failed. You should make code easy to read, because many will read it after it's created, don't use complex constructs, do the things in the natural way.
The most frustrating thing for me as a software engineer is that people do not take the time to architect the solution (frustrating because I am picking up after them). Software engineers usually just jump into coding without really thinking about the overall design-the actual engineering. To me, it’s the most important part, and it ends up making all the other code you write fall into place much more easily.
This is fantastic advice. As an engineer I would always focus on'first, just get it going', to demonstrate the principle. Once done and accepted, i would throw that code away and start fro scratch to get it done properly. As an engineering manager, I once had to fire someone who couldn't upgrade his own very slow code - he was so reliant on a a particular method and set of tools that there was no way forward for him. So take this advice from Gordon to heart!
Most of my best ideas come while lying in bed. One particular solution came in a dream, and I was lucky to remember enough to act on it. Another place to have good ideas is the shower, complicated by the fact that you can't have a notepad or voice recorder or mobile phone with you. Sometimes, after wrestling with a crap idea on how to do something, you realise the desperation of persisting with it, and that sets off the subliminal thought processes that lead to the aforementioned ideas popping up, not always at times when you could write them down. I developed the practice of writing down every idea before it disappears again, partly because it might be useful, as a memory jogger if nothing else, and partly because of the anxiety reduction that follows having got it onto permanent storage so you don't have to try desperately to not forget it. Late at night when sleep is on its way, imagination is approaching its height, kicking off a torrent of ideas, if you happen to be in the right mood, with some bee in your bonnet at the time. I suspect that is why so many programmers do their best work after midnight. I remember reading somewhere that that is true of about half of all programmers. If anyone has any more accurate info, please enlighten us.
The first step is come up with a list of testable requirements. Analyze how all the bits fit together, then design effective maintainable modules, then the coding step, with a full set of coding standards! It needs to be maintainable. Test the devil out of it. Does it pass all the requirements tests? Pass it off for user testing.. write user manuals... everything signed off, schedule the release.. this is the pint sized version of 400ish pages of software development standards for all levels.
Agreed, but its not the programming, what is the key. A perfect Business process design needs to be done first, it leads to those kind of clear Data and technical Design, what then completes a mostly perfect App when done with those programming skills you mentioned.
I've been a programmer for 47 years now, to me the best possible code is the one where the design is such that there are no exceptions, there are no inline branches, nothing to slow down the CPU pipeline(s). For many years I had word count (wc) as my benchmark program on every new (x86) microarchitecture: As I went from 8088 via 286, 386 and 486 to Pentium, my "optimal" code changed for every CPU iteration. Finally, on the Pentium I found that I could create a state machine which consistently handled two input characters every three clock cycles, counting lines, words and characters while allowing user-specified word and line separators. That code broke completely (performance-wise) on the PentiumPro, so I had to switch to a model where I have 4-5 different algorithms and benchmark them all on the first 4kB of input before deciding which one to use on the remaining data. It is only after the advent of utf8 everywhere that I have felt the need to revisit that 25+ year old code. My point here is that what you call Level 3 is what I term elegance, something many (most?) programmers are unable to recognize when they see it.
What about 4. Maintainability/Readability? Even well-designed and working code can often be a nightmare to read, especially in cases where unnecessary effort was put into optimization. For example in a method that handles a button click, there's just no point in doing one-liners, minimizing number of variables and other kinds of optimization that degrade readability.
I develop 3D software. My main application that I sell is currently at about 1.1 million lines of code that took me about 10 years to write. It is written well enough that I can go back into any section, expand it, and not break anything in the software. For me, code layout and organization is high priority, and documenting the code is key, and using logical programming paradigms. It has taken me more than five decades of programming experience to get to this point though. I started in the 1970's with an HP punch card computer, then assembler on a dozen 8-bit microprocessors, and on to PC's with C, C++, C#, BASIC, and other languages.
Hello sir, I got some questions that are totally unrelated to the video content, but since u have experience on such massive project - I have heard about a saying that among numerous problems that a software occurs to, those involves parallelism and multi-threading are the ones that are most difficult to solve. I wonder if you agree to such saying, that below the architecture level such problems are usually the hardest. And another question is how do you acknowledge logical programming paradigms? I know Prolog is something for logic programming, and I suppose there're actually quite few paradigms other than that - FP, OOP, C-like process-oriented and nothing else
I’m a bit younger but having also worked on PDP-11 in 1995 and written lots and lots of assembly on 8,16 and even 32/64 bit CPUs. We know how to break down things to the simplest bits as that’s the only way to develop in assembly.
The only reliable thing about programming is that nothing is 100 percent reliable. This is why you beta test. This is why you have "bug fixes" No one can think of every possible scenerio. There are billions of possibilities, to consider each and every one, and reliably have a perfect code on attempt 1 is impossible.
Done that. The DB2 optimiser was not ideal. So I had to figure out with Spufi abd Explain what to do. Next I had to figure out HOW to do it. And knowing something about quirks of B+ trees was a bonus.
I've found for myself that the next teir was the documentation of the ideas underpinning the code. You can't alwas just do this as comments because the mechanics can be all over the shop. Documentation allows you to co-ordinate your coding. It 's not just an afterthought. I can come back to my code base at anytime and from the current documentation see why I was doing something in the way that I did.
I also think there is another thing that is even more rare and more important. It's taking responsibility and be accountable for the result. Not just "I closed the task in jira", but "I've made it working, I'm responsible for the consequences if it brings a headache".
