Interested in PAIR PROGRAMMING & want some tips for success? Find my FREE DOWNLOADABLE GUIDE on pair programming HERE ➡ www.subscribepage.com/cd-pair-guide
Git usage and debugging techniques with an IDE (outside of printf's) are the two biggest shortfalls I've experienced as a graduate(nearly 10 years ago) and from graduates we hire today. Universities place near to no emphasis on SDLC on the delivery of their assignments and it filters into the industry with developers who don't see managing their release pipelines as part of their job. IMO good junior developers are humble about what they do and don't know, confident enough to communicate it, and eager enough to dive into projects and ask questions to find out what they need. That attitude is the core of being a good developer, you're going to be doing it for your whole career.
@@leonf.7893 Git I can kind of understand, but debugging in an IDE. It's mad, we had the latest Visual Studio release for the whole time I was studying and there was near to no instruction on placing breakpoints and examining the stack. I had a young guy taking pride that he didn't need a debugger and printf's were enough. That lasted about a month before he was placing breakpoints and conditionals, he was a smart lad but it was the culture of weird purity tests where you need to be the VIM superuser who doesn't need documentation that fails people and prevents them from really getting things done.
Where did you learn debugging techniques? Because I feel like there's a whole world out there that I don't know about, such as using git bisect scripts to find the first git SHA that introduced a bug or whatever.
A lot of the issue in University settings is that you often get a "problem of the week" to solve, then the next week there is a new problem. You mostly work alone and you seldom have to live with the solution you made in the past. I wish that the majority of tasks was a two person tasks and that most built on top of each other. That would teach the students code hygiene, refactoring, unit testing, documentation, version control and collaboration. At the time of dinosaurs, when I was in University, we only had two courses in year 4 that could constitute a "real project". One was building a controller and data collector for hardware SPI laboratory equipment. And the other was building a microcomputer simulator in Java (registers, memory/page handling, interrupts, and all), an microkernel operating system to run on said microcomputer and a compiler/linker to go with it. That was really messy since we never had properly learned to be software engineers and work as a team.
Some of this is university requirements. I utilised a library I had written in a previous module as a building block for my present one. What resulted was an argument with the university administrators over "self plagiarization". In my case we were being marked on procedural terrain generation, and I had used a game engine using systems I had handed in in one of our graphics modules. Luckily I had the support of my course leader since he had designed the curriculum to be escalating by design. But it shows one of the friction points a university grading system can have up against software development.
I agree with you that having a group of (two or more) students would be beneficial for them but also has a few problems. Specially because, if collaboration goes out the window, so does everything else you mentioned. My degree is in electronics so there was not much emphasis on version control, unit testing and other more software related stuff. But I hope nowadays there is because that is very important to hardware too. In my university (long ago), we only had one or two projects a year and, when working in groups, the work almost always ended up being all (secretly) made by just one of the students. This increases the workload of the teacher if he wants to evaluate students individually because it is difficult to really know who made what. If the teacher does not want the extra work, he will potentially give a good grade to someone that does not know anything, resulting in future bad professionals. I describe next a bad experience that I had, you can skip it if you want. Begin rant :) One of the projects I had was also a controller for laboratory equipment but using RS-485 (distributed controller with distributed user command terminals communicating using token ring over 2x RS-485). It was supposed to be me plus another student. We agreed that I would make the hardware and the low-level software in assembly ("kernel" for controllers and terminals, implement the token-ring for communications and an API with C bindings for controlling the hardware using a high-level language), because I was best at assembly, and he would implement the software that runs on top (TUI for terminals, implement the controller logic for the lab equipment, etc) using the API we defined. All my work was done in two weeks but had a bug that I could not find and asked the teacher for help (which he never gave because he was always too busy). The next two months I spent trying to catch the bug, chasing the teacher for help, and chasing my colleague to check when he would be finished with his part (to try and get him to see my part and maybe catch the bug I was missing). But my colleague's schedule was different from mine, we never had time to meet "on school hours", and he was unwilling to stay after hours. One hour before the deadline, he sent me an angry email with his code written in C++ (ignoring the API we defined), saying that he complained to the teacher that I did not do anything and I would not meet with him, to which the teacher gave him a B for effort and gave me an F without even seeing me to hear my side or present my part. I ended passing the class with a minimum grade because I aced the final test. Eventually I found the bug and it was down to a misspelled word. The assembly instructions for the chip we were using had almost identical names for the serial data and serial interrupt. The interrupt had an extra "i" in the middle of the name, making it extra hard to spot.
@@boam2943 I think individually grading students in a group task is a fools endeavour. Like all things in life exceptions should be made (I've worked with awful team players as well). With the proper evidence a tutor can decide if they need to proportion out percentages of a grade differently.
I never went to university. I've been writing code since I was 13 (I am 46 now). Theres a ton of things I don't know. And I keep telling this to my Juniors, you dont have to know everything. I am Technical Lead at my company, it's difficult to keep Juniors grounded and not to worry about every little thing. The trick is having the ability to learn and catch on quickly. As long as you have an aptitude to this industry it'll be fine.
What if someone struggles with the ability to learn quickly and relies more on hard and prolonged hours of work? Would it be harder to catch up later on?
That really was my take away from this video. I've done 40 years in IT this year and for most of that time, I've been paid by people to fix their problems. I've never been to a university course, and in the beginning, I didn't even have books. I learned things out of magazines like BYTE magazine, words I didn't even understand. But what I found, is that because I learned the hard way, I somehow learned how to learn much faster than my supposed peers. Learning "how to learn" is the most important skill there is. You have to break it down to "what's the most important thing I need to understand?" and work outwards from there.
Boy was I lucky to learn programming for 3 months as a trainee at an engineering company. Everyone else had taken that route so getting integrated into a team went smooth like baby's feet. Questions were encouraged and everyone was extremely patient helping folks just out of training learn the ropes.
Personally I think any good University education should be at least one-quarter working with an experienced team on real projects like an internship. Maybe as much as three-quarters of their schooling should be that. Some of the best developers I've ever worked with had little to no schooling, they just drove in and started learning it themselves.
@@aaronbono4688 I've never had a programming class in my life. My major was English Lit. Even the training course for 370 assembler was an IBM self-directed course. At one point I contemplated getting a degree until a colleague who was going for his Masters (or was it PHD?) in CS told me not to bother. "You already know way more than they do." So I cannot comment on how universities teach CS...
@@brownhorsesoftware3605 the computer science classes I took were garbage, I got my degree in math and my masters in statistics. I can say that my Master's degree has gotten me higher pay consistently throughout my career but at the same time it took me over eight years to get that degree so basically I guess I'm playing catch-up for all the years when I was earning almost nothing.
@@aaronbono4688 I think the most important thing for success writing software is the ability and tendency to dive head first into a topic at the drop of a hat and continue diving until you have a grasp of it. I don't know how to teach that.
@@brownhorsesoftware3605 you teach people to think critically and you teach them how to do research and you teach them how to enjoy the process and not fear how to work this way.
Thanks. Yes, Trish has valuable experience and advice to share on Java, high-performance computing, coaching and mentoring developers. She also has a new book out 👉 leanpub.com/gettingtoknowIntelliJIDEA
Excellent discussion, I think it raised a good question: How to get people trained and skilled to work on software? Presently there's a disconnect between knowing how to code and coding in a professional manner using principles (like SOLID)... These are different skill sets and the principles rely on the ability to do the coding well... there are at least two learning curves to climb at the same time. But let's not stop at Junior Developers! What I face in the workplace with very bright, experienced, and seasoned programmers with years under their belts is that they haven't been exposed to principles such as SOLID and while they can code and problem solve at a very high level, they do things in their code, at times, that I must say, and sorry to say, are cringeworthy... It's not a personal thing if they chose to implement using a global variable or hardcode knowledge, and tightly couple things or make "include the world" header files, etc. But they take it personal when I point these things out... Maybe it's the way I said it ? I might have been a bit harsh, not intending to, But my constructive criticism has backfired to "shoot the messenger" and since I'm the low man on the totem pole and have no power to change things anyway... Thus the code continues to be written in the way that it's always been written. Sadly, I've seen this movie before and I know how it ends.
I know a graduate and I've discussed my problems with moving jobs ("you can't do this job unless you have 4 years experience on our exact tech stack")... and he has said that that's precisely what he found trying to get his FIRST job... "no you can't have a junior role until you have 4 years commercial experience"... how exactly he's supposed to get that experience without having that experience remains a mystery to both of us. The fact that either of us KNOW anything seems utterly irrelevant to the recruiters we talk too, you must have actually had a job (for the "magical" 4 years) where it is used.
I loved this video. I’m a new developer, the company I work for ran a 16 week bootcamp and after that we were put into teams, so I literally know nothing… one of the biggest things I struggle with is knowing what I need to learn. I’ve done tutorials on things like Kubernetes but I don’t know what’s relevant and what isn’t.
Something that's served me well is following a technique I used to use with textbooks. Scan the documentation through it's headings, it usually identifies what it wants you to know about it. If you need to dig deeper than give a related page a read. Don't be afraid to take more than one "technology solution" to a problem and read them, maybe one is more opinionated towards the solution you require than another. If the documentation is poor, the code is poor, the support will be poor and the release cadence is poor. Documentation is the core of what I value because when I choose a technology I need to build a shared understanding of it within my organisation. Bad documentation hinders this effort.
Early on, you should only have to learn things that come up as part of your job. No need to add anything else to the mix that you *feel* might be relevant. Your goal in the beginning is to become comfortable with the tools and frameworks that your team uses, so that you can be productive. As a junior, you'll probably get assigned a task or two at a time with more or less step by step instructions (like add this button here and make it look like this and call such and such API). As you work on those tasks you will have tons of questions. Work with your team to figure out the answers to those. Note that early on your questions will mostly be centered around the "what" and the "how" of software development. Eg what is git, how do I open a PR, how do I access the right theme color to style my button, how do I make the API request, how do I make changes to the database schema, etc. This is all fine and will keep you busy for a few years. Also note that initially the what/how questions will be centered around how *your* team/company do things, but as you progress you should start asking these questions in general (eg instead of "how do I create a button using my company's shared components library" you should be moving on to "how do I create a button in React" and then to "how do I create a button from scratch" or "what does it mean to make a good button"). The goal as you move from junior to mid is to escape your company's sandbox and be able to be productive at *any* company, because you know how things work in general, not just on your team. Finally as you move to senior and staff the "what" and the "how" mostly turn into "why" and other similarly vague questions. Eg "which database should we use" and "is Kubernetes right for this project." Beyond staff - I'm not sure, though the most complicated questions appears to be "what features should we focus on to maximize revenue." Seems impossible to answer, that one.
My gripe was the use of the word technology for a new framework language or database style. To me they are all variations on a theme. But I totally agree that total mastery of the command 'dictionary' of any tool is pointlessly. The thing, I look for is the control statements ie how many ways you can loop and make choices, and how flexible the data structures are in building larger custom ones.
I think this gets to the core of why I hate certifications. Certifications expect you to know everything about something and most of what you have to learn in order to earn a certification is crap you'll never need to know. It's really frustrating to have to spend a bunch of time when you know it's wasted on topics you don't need to learn.
I studied Electrical Engineering and before graduation I used to think that I'd have to be a "one-man Army" in industry. It was quite scary at the time, but thankfully work turned out to be very different from that. That misconception scared me off of embedded systems programming which I honestly had an interest in, but I decided to stay away from programming altogether because of my misguided ideas and lack of real world knowledge/guidance.
Exactly, it even feels like the whole Stack overflow voting system and restrictions on those who don't have enough points is set up in exactly that way. A newbie cant post something as simple yet helpful as a damn comment. newbies should just shut up or ask a question the end. Stack overflow fits right into that bit you highlighted.
First: very good phrasing, how Trisha explained the issue. One sees, how she is successful in advocacy; very good speaking. Then... on a word in regards of presenting (it occurred to me also on other videos and the series): Trisha was never full screen, always side-by-side. Dave was always full-screen, hiding Trisha away. Also the progress over time is funny. First Dave on a small side-by-side screen, then on the same size side-by-side, when Trisha spoke. As the series is more about the guests than the host, I'd like to ask, if you might want to actually switch that.
There is a skill is being able to find things out. Both google-fu and finding the 'right' person in the company that knows about the thing or has the right permissions.
My advice to junior developers for a job interview is to be confident if interviewer is confident and to show enthusiasm for the job they are applying. I think this is more important than the current knowledge they have.
Problem driven learning. Use whatever resource that's at your disposal, be it ChatGPT, google, colleagues etc. And get used to knowing nothing at all quickly ;) Getting hired also depends largely on hiring strategy of the companies. Some hire by matching cv with job opening and filter based on that without so much as a meeting. Some let teams invite candidates and let the team decide who is most suitable.
That is so interesting towards the end of the video that in pair programming, there should be a mentality that we're here together to complement each other's knowledge. How do I instill that value in my team? I am a big believer in pair programming (and TDD) but once I mentioned these 2 practices (that we're not doing), they kind of 'shy away' from it and said that every developer has their own way .. :(
Hm. What i experience now more and more, is that juniors are thrown into a "scrum" team together with a "scrum master" (aka junior project micro manager) who made a 2 day scrum training and a couple "senior" developers with 1 year experience and they start to build software and after 12-18 month the mess is not maintainable anymore thanks to flaccid scrum as Fowler describes it. And then internal or external experts are flown in to rescue the project and those teams struggle with absolut basic skills (like understanding what thread-safety means), but they are surprisingly arrogant and explain people with 15-20 years of experience each what you are not allowed to do in agile and that there is nothing wrong with that giant ball of unstructured code they can't maintain anymore and it's the customers fault anyway. The tipp i would give junior developers: try to get into a project with at least one very experienced (and hopefully good) developer and annoy him (pair programming, code reviews, discuss solutions...). It's humbling to see how much you don't know and how much experience adds to every aspect of this job, even when you are just naming a package or interface. Oh and if you find a project running smooth with a great structured and tested code base, learn from it. There are people who look at a package with clear name and clearly named content and then create a new class in there who a 5 year old would immediately find the thing which does not fit. Look for patterns, understand the patterns and copy them until you have seen enough to recognize the flaws and then improve them. Being in a "young and unexperienced, but super motivated" team is a bad way to start into this career.
the ideal team has a junior in it, if for no other reason than to ask the questions all the others know in their bones are stupid, but still need asking hiring only senior developers is stupid
Nice and true, but only from the perspective of a highly trained and established person in the field. You don’t „come to a new team“ not knowing it‘s stack and being inexperienced in this explicit field. You wouldn’t get hired. Maybe talk about how to achieve that. I am absolutely with you about the „can’t know everything“ part.
One very important thing at start of career is to run far away from people who tell to use things/apis/libs/frameworks as black box and not drill deep....new graduates must drill as deep as possible whatever they are learning
Complete horseshit. The entire POINT of abstraction is to reuse solutions to solve even bigger problems. You can write a useful full stack app while being blissfully unaware of the OSI model OR pointers.
@@adambickford8720 write whatever you want using abstractions......but without digging into frameworks, apis, libraries you wont learn much except becoming a code monkey...
Higher education tends to focus on computer science theory versus practical software engineering practices. It's less effort. It's easier to teach theory which evolves slowly versus trying to keep up with the frenetic pace of change in modern software engineering.
I think the hiring industry expects people like Dave straight out of university. That's why everyone keeps getting the wrong impression about what is required to be hire-able.
The problem is that you can miss entire paradigm shifts because you don't want to learn the current 'fad'. Reskilling from near ground 0 vs absorbing along the way can create a self-perpetuating obsolescence cycle. Take java 8; that's not just an api, it's a fundamental shift in thinking. I've interviewed folks who clearly haven't learned much after java 5 and they are basically useless now. The trick is cherry picking things that will be helpful in the future, which is largely unknowable.
Universities are just too academic and too detached from reality. They pretty much assume that you will get a PhD instead of a job. Then you get a job and you realise almost nothing they taught you is useful at all. You need to work in a team, use tools, design and develop features for users to actually use, keep working in the same codebase for a long time and so be able to keep it maintainable with safe refactoring, track down bugs etc. Graduates have often never even heard of writing unit tests and when you try to explain it to them they think it's a waste of time, because they are testing that the code is what the code is, rather than testing it has the desired behaviour. But I mean I guess they know what a red-black tree is.
I think there's value in the academic system in that I think it exposes a lot of students to an environment where they have to "learn to learn" in order to succeed. Speaking solely as a product of the UK education system. It's the first time I was exposed to such an environment. It's so important that I would advise any aspiring software developer to go to university or "higher education" to this day. But you're right, the way many courses are structured do not share the same values as actual software companies operating today. I think a mix of greenfield and brownfield projects through a software developers curriculum would be beneficial. Always moving towards collective teamwork in projects as the course progresses. What do you think?
SOLID is important if job interviewer is a highly experienced software developer. If manager is doing the job interview then looking confident is more important than what you say. LOL!
@@tongobong1 absolutely i do agree... industry has more of those people who wanna hear random high impact tools and new shiny tech instead of actual pragmatic approaches to problem solving and business development. This mentality leads to over complexity and technical debt later on. Also every line of code isn't an asset but a liability lol
@@tongobong1 also i would like to add that knowing the fundamentals principles is far more important than any technology. Knowing the principles makes you understand the problem in depth and only after that you can choose the right tool to solve it.
@@aakarshan4644 the important part is also understanding the wars between different opinions about unit testing and styles, using TDD or not, agile vs waterfall... and stay away from that topics because you never know what are interviewer's preferences. Once a manager on a job interview asked me if I am one of those that like to write unit tests - he clearly hated unit tests. Since technical lead was also present and he clearly liked unit tests I answered very diplomatically that unit tests are sometimes useful but this was not good enough answer for manager that clearly wanted to hear that I don't like unit tests... LOL Beside can you imagine that there are many experienced developers in Europe that are still writing London style unit tests? That they still didn't realized how terrible is to mock out everything that is not a part of the class under test?
@@tongobong1 Oh man that is rough. I have no idea how to be diplomatic in tech lol, but i guess i have to keep my opinions to myself during an interview. This TDD and agile and E2E and the new one kubernetes lol. In the unit test example you wrote perhaps the best way is to just point to the timeline of the project deliverables and make a trade-off argument of interaction speed vs reliability(Unit Test). Still if some one is a fan of TDD or speed or any one approach to development its hard to convince them for your case. I heard somewhere that the best way to interview is to first read the interview him/herself and then go with the vibes lol. In the end in big tech you have enough red tape and processes that only decent+ engineering goes into production, in small to mid startups you're mostly putting out production fires lol.
Interested in PAIR PROGRAMMING & want some tips for success? Find my FREE DOWNLOADABLE GUIDE on pair programming HERE ➡ www.subscribepage.com/cd-pair-guide
The key is: Work with people that say and believe “you can’t know everything, but learn anything”.
Git usage and debugging techniques with an IDE (outside of printf's) are the two biggest shortfalls I've experienced as a graduate(nearly 10 years ago) and from graduates we hire today. Universities place near to no emphasis on SDLC on the delivery of their assignments and it filters into the industry with developers who don't see managing their release pipelines as part of their job.
IMO good junior developers are humble about what they do and don't know, confident enough to communicate it, and eager enough to dive into projects and ask questions to find out what they need. That attitude is the core of being a good developer, you're going to be doing it for your whole career.
I too experienced a lack of Git and debugging knowledge after graduation. It hit me hard when I got my first job.
@@leonf.7893 Git I can kind of understand, but debugging in an IDE. It's mad, we had the latest Visual Studio release for the whole time I was studying and there was near to no instruction on placing breakpoints and examining the stack.
I had a young guy taking pride that he didn't need a debugger and printf's were enough. That lasted about a month before he was placing breakpoints and conditionals, he was a smart lad but it was the culture of weird purity tests where you need to be the VIM superuser who doesn't need documentation that fails people and prevents them from really getting things done.
Agreed people like that can really grow and even sometime outpase those with talent.
Where did you learn debugging techniques? Because I feel like there's a whole world out there that I don't know about, such as using git bisect scripts to find the first git SHA that introduced a bug or whatever.
A lot of the issue in University settings is that you often get a "problem of the week" to solve, then the next week there is a new problem.
You mostly work alone and you seldom have to live with the solution you made in the past.
I wish that the majority of tasks was a two person tasks and that most built on top of each other. That would teach the students code hygiene, refactoring, unit testing, documentation, version control and collaboration.
At the time of dinosaurs, when I was in University, we only had two courses in year 4 that could constitute a "real project". One was building a controller and data collector for hardware SPI laboratory equipment. And the other was building a microcomputer simulator in Java (registers, memory/page handling, interrupts, and all), an microkernel operating system to run on said microcomputer and a compiler/linker to go with it. That was really messy since we never had properly learned to be software engineers and work as a team.
Some of this is university requirements. I utilised a library I had written in a previous module as a building block for my present one. What resulted was an argument with the university administrators over "self plagiarization". In my case we were being marked on procedural terrain generation, and I had used a game engine using systems I had handed in in one of our graphics modules.
Luckily I had the support of my course leader since he had designed the curriculum to be escalating by design. But it shows one of the friction points a university grading system can have up against software development.
I agree with you that having a group of (two or more) students would be beneficial for them but also has a few problems. Specially because, if collaboration goes out the window, so does everything else you mentioned.
My degree is in electronics so there was not much emphasis on version control, unit testing and other more software related stuff. But I hope nowadays there is because that is very important to hardware too.
In my university (long ago), we only had one or two projects a year and, when working in groups, the work almost always ended up being all (secretly) made by just one of the students.
This increases the workload of the teacher if he wants to evaluate students individually because it is difficult to really know who made what. If the teacher does not want the extra work, he will potentially give a good grade to someone that does not know anything, resulting in future bad professionals.
I describe next a bad experience that I had, you can skip it if you want. Begin rant :)
One of the projects I had was also a controller for laboratory equipment but using RS-485 (distributed controller with distributed user command terminals communicating using token ring over 2x RS-485). It was supposed to be me plus another student.
We agreed that I would make the hardware and the low-level software in assembly ("kernel" for controllers and terminals, implement the token-ring for communications and an API with C bindings for controlling the hardware using a high-level language), because I was best at assembly, and he would implement the software that runs on top (TUI for terminals, implement the controller logic for the lab equipment, etc) using the API we defined.
All my work was done in two weeks but had a bug that I could not find and asked the teacher for help (which he never gave because he was always too busy). The next two months I spent trying to catch the bug, chasing the teacher for help, and chasing my colleague to check when he would be finished with his part (to try and get him to see my part and maybe catch the bug I was missing). But my colleague's schedule was different from mine, we never had time to meet "on school hours", and he was unwilling to stay after hours.
One hour before the deadline, he sent me an angry email with his code written in C++ (ignoring the API we defined), saying that he complained to the teacher that I did not do anything and I would not meet with him, to which the teacher gave him a B for effort and gave me an F without even seeing me to hear my side or present my part. I ended passing the class with a minimum grade because I aced the final test.
Eventually I found the bug and it was down to a misspelled word. The assembly instructions for the chip we were using had almost identical names for the serial data and serial interrupt. The interrupt had an extra "i" in the middle of the name, making it extra hard to spot.
@@boam2943 I think individually grading students in a group task is a fools endeavour. Like all things in life exceptions should be made (I've worked with awful team players as well). With the proper evidence a tutor can decide if they need to proportion out percentages of a grade differently.
I never went to university. I've been writing code since I was 13 (I am 46 now). Theres a ton of things I don't know. And I keep telling this to my Juniors, you dont have to know everything. I am Technical Lead at my company, it's difficult to keep Juniors grounded and not to worry about every little thing. The trick is having the ability to learn and catch on quickly. As long as you have an aptitude to this industry it'll be fine.
What if someone struggles with the ability to learn quickly and relies more on hard and prolonged hours of work? Would it be harder to catch up later on?
"I'm a reduced instruction set developer" What a profound off the cuff statement. Truly brilliant.
That really was my take away from this video.
I've done 40 years in IT this year and for most of that time, I've been paid by people to fix their problems.
I've never been to a university course, and in the beginning, I didn't even have books. I learned things out of magazines like BYTE magazine, words I didn't even understand.
But what I found, is that because I learned the hard way, I somehow learned how to learn much faster than my supposed peers.
Learning "how to learn" is the most important skill there is.
You have to break it down to "what's the most important thing I need to understand?" and work outwards from there.
Boy was I lucky to learn programming for 3 months as a trainee at an engineering company. Everyone else had taken that route so getting integrated into a team went smooth like baby's feet. Questions were encouraged and everyone was extremely patient helping folks just out of training learn the ropes.
Personally I think any good University education should be at least one-quarter working with an experienced team on real projects like an internship. Maybe as much as three-quarters of their schooling should be that. Some of the best developers I've ever worked with had little to no schooling, they just drove in and started learning it themselves.
@@aaronbono4688 I've never had a programming class in my life. My major was English Lit. Even the training course for 370 assembler was an IBM self-directed course. At one point I contemplated getting a degree until a colleague who was going for his Masters (or was it PHD?) in CS told me not to bother. "You already know way more than they do." So I cannot comment on how universities teach CS...
@@brownhorsesoftware3605 the computer science classes I took were garbage, I got my degree in math and my masters in statistics. I can say that my Master's degree has gotten me higher pay consistently throughout my career but at the same time it took me over eight years to get that degree so basically I guess I'm playing catch-up for all the years when I was earning almost nothing.
@@aaronbono4688 I think the most important thing for success writing software is the ability and tendency to dive head first into a topic at the drop of a hat and continue diving until you have a grasp of it. I don't know how to teach that.
@@brownhorsesoftware3605 you teach people to think critically and you teach them how to do research and you teach them how to enjoy the process and not fear how to work this way.
I could binge-watch videos of Trisha all day 💁♀️. Thanks again for hosting great folks like her 🙏
Yay! Thank you!
Another great guest. It's good to hear very experienced people talk about what they don't know.
Thanks. Yes, Trish has valuable experience and advice to share on Java, high-performance computing, coaching and mentoring developers.
She also has a new book out 👉 leanpub.com/gettingtoknowIntelliJIDEA
Excellent discussion, I think it raised a good question: How to get people trained and skilled to work on software? Presently there's a disconnect between knowing how to code and coding in a professional manner using principles (like SOLID)... These are different skill sets and the principles rely on the ability to do the coding well... there are at least two learning curves to climb at the same time. But let's not stop at Junior Developers! What I face in the workplace with very bright, experienced, and seasoned programmers with years under their belts is that they haven't been exposed to principles such as SOLID and while they can code and problem solve at a very high level, they do things in their code, at times, that I must say, and sorry to say, are cringeworthy... It's not a personal thing if they chose to implement using a global variable or hardcode knowledge, and tightly couple things or make "include the world" header files, etc. But they take it personal when I point these things out... Maybe it's the way I said it ? I might have been a bit harsh, not intending to, But my constructive criticism has backfired to "shoot the messenger" and since I'm the low man on the totem pole and have no power to change things anyway... Thus the code continues to be written in the way that it's always been written. Sadly, I've seen this movie before and I know how it ends.
I know a graduate and I've discussed my problems with moving jobs ("you can't do this job unless you have 4 years experience on our exact tech stack")... and he has said that that's precisely what he found trying to get his FIRST job... "no you can't have a junior role until you have 4 years commercial experience"... how exactly he's supposed to get that experience without having that experience remains a mystery to both of us. The fact that either of us KNOW anything seems utterly irrelevant to the recruiters we talk too, you must have actually had a job (for the "magical" 4 years) where it is used.
I loved this video. I’m a new developer, the company I work for ran a 16 week bootcamp and after that we were put into teams, so I literally know nothing… one of the biggest things I struggle with is knowing what I need to learn. I’ve done tutorials on things like Kubernetes but I don’t know what’s relevant and what isn’t.
Something that's served me well is following a technique I used to use with textbooks. Scan the documentation through it's headings, it usually identifies what it wants you to know about it. If you need to dig deeper than give a related page a read. Don't be afraid to take more than one "technology solution" to a problem and read them, maybe one is more opinionated towards the solution you require than another.
If the documentation is poor, the code is poor, the support will be poor and the release cadence is poor. Documentation is the core of what I value because when I choose a technology I need to build a shared understanding of it within my organisation. Bad documentation hinders this effort.
Early on, you should only have to learn things that come up as part of your job. No need to add anything else to the mix that you *feel* might be relevant. Your goal in the beginning is to become comfortable with the tools and frameworks that your team uses, so that you can be productive.
As a junior, you'll probably get assigned a task or two at a time with more or less step by step instructions (like add this button here and make it look like this and call such and such API). As you work on those tasks you will have tons of questions. Work with your team to figure out the answers to those.
Note that early on your questions will mostly be centered around the "what" and the "how" of software development. Eg what is git, how do I open a PR, how do I access the right theme color to style my button, how do I make the API request, how do I make changes to the database schema, etc.
This is all fine and will keep you busy for a few years. Also note that initially the what/how questions will be centered around how *your* team/company do things, but as you progress you should start asking these questions in general (eg instead of "how do I create a button using my company's shared components library" you should be moving on to "how do I create a button in React" and then to "how do I create a button from scratch" or "what does it mean to make a good button").
The goal as you move from junior to mid is to escape your company's sandbox and be able to be productive at *any* company, because you know how things work in general, not just on your team.
Finally as you move to senior and staff the "what" and the "how" mostly turn into "why" and other similarly vague questions. Eg "which database should we use" and "is Kubernetes right for this project."
Beyond staff - I'm not sure, though the most complicated questions appears to be "what features should we focus on to maximize revenue." Seems impossible to answer, that one.
Thank you for this video. Imposter syndrome is difficult.
My gripe was the use of the word technology for a new framework language or database style. To me they are all variations on a theme.
But I totally agree that total mastery of the command 'dictionary' of any tool is pointlessly.
The thing, I look for is the control statements ie how many ways you can loop and make choices, and how flexible the data structures are in building larger custom ones.
I think this gets to the core of why I hate certifications. Certifications expect you to know everything about something and most of what you have to learn in order to earn a certification is crap you'll never need to know. It's really frustrating to have to spend a bunch of time when you know it's wasted on topics you don't need to learn.
1:44 totally agree! One can know only 20% of, let's say Git commands, and that will be enough for 80% of daily tasks.
I studied Electrical Engineering and before graduation I used to think that I'd have to be a "one-man Army" in industry. It was quite scary at the time, but thankfully work turned out to be very different from that. That misconception scared me off of embedded systems programming which I honestly had an interest in, but I decided to stay away from programming altogether because of my misguided ideas and lack of real world knowledge/guidance.
6:44 summary of stack overflow moderators
Exactly, it even feels like the whole Stack overflow voting system and restrictions on those who don't have enough points is set up in exactly that way.
A newbie cant post something as simple yet helpful as a damn comment. newbies should just shut up or ask a question the end. Stack overflow fits right into that bit you highlighted.
First: very good phrasing, how Trisha explained the issue. One sees, how she is successful in advocacy; very good speaking.
Then... on a word in regards of presenting (it occurred to me also on other videos and the series): Trisha was never full screen, always side-by-side. Dave was always full-screen, hiding Trisha away.
Also the progress over time is funny. First Dave on a small side-by-side screen, then on the same size side-by-side, when Trisha spoke.
As the series is more about the guests than the host, I'd like to ask, if you might want to actually switch that.
There is a skill is being able to find things out. Both google-fu and finding the 'right' person in the company that knows about the thing or has the right permissions.
My advice to junior developers for a job interview is to be confident if interviewer is confident and to show enthusiasm for the job they are applying. I think this is more important than the current knowledge they have.
Problem driven learning. Use whatever resource that's at your disposal, be it ChatGPT, google, colleagues etc. And get used to knowing nothing at all quickly ;)
Getting hired also depends largely on hiring strategy of the companies. Some hire by matching cv with job opening and filter based on that without so much as a meeting. Some let teams invite candidates and let the team decide who is most suitable.
That is so interesting towards the end of the video that in pair programming, there should be a mentality that we're here together to complement each other's knowledge. How do I instill that value in my team? I am a big believer in pair programming (and TDD) but once I mentioned these 2 practices (that we're not doing), they kind of 'shy away' from it and said that every developer has their own way .. :(
Hm. What i experience now more and more, is that juniors are thrown into a "scrum" team together with a "scrum master" (aka junior project micro manager) who made a 2 day scrum training and a couple "senior" developers with 1 year experience and they start to build software and after 12-18 month the mess is not maintainable anymore thanks to flaccid scrum as Fowler describes it. And then internal or external experts are flown in to rescue the project and those teams struggle with absolut basic skills (like understanding what thread-safety means), but they are surprisingly arrogant and explain people with 15-20 years of experience each what you are not allowed to do in agile and that there is nothing wrong with that giant ball of unstructured code they can't maintain anymore and it's the customers fault anyway.
The tipp i would give junior developers: try to get into a project with at least one very experienced (and hopefully good) developer and annoy him (pair programming, code reviews, discuss solutions...). It's humbling to see how much you don't know and how much experience adds to every aspect of this job, even when you are just naming a package or interface.
Oh and if you find a project running smooth with a great structured and tested code base, learn from it. There are people who look at a package with clear name and clearly named content and then create a new class in there who a 5 year old would immediately find the thing which does not fit. Look for patterns, understand the patterns and copy them until you have seen enough to recognize the flaws and then improve them. Being in a "young and unexperienced, but super motivated" team is a bad way to start into this career.
Great video, thank you for the detailed explanation with an examples.
I usually say to new guys: don't be shamed to ask.
Other one: A team is always smarter than its members separately. (So your comments are welcomed.)
the ideal team has a junior in it, if for no other reason than to ask the questions all the others know in their bones are stupid, but still need asking
hiring only senior developers is stupid
Nice and true, but only from the perspective of a highly trained and established person in the field.
You don’t „come to a new team“ not knowing it‘s stack and being inexperienced in this explicit field. You wouldn’t get hired.
Maybe talk about how to achieve that.
I am absolutely with you about the „can’t know everything“ part.
One very important thing at start of career is to run far away from people who tell to use things/apis/libs/frameworks as black box and not drill deep....new graduates must drill as deep as possible whatever they are learning
Complete horseshit. The entire POINT of abstraction is to reuse solutions to solve even bigger problems. You can write a useful full stack app while being blissfully unaware of the OSI model OR pointers.
@@adambickford8720 write whatever you want using abstractions......but without digging into frameworks, apis, libraries you wont learn much except becoming a code monkey...
" Doing What Works to Build Better Software Faster" is out of print in the USA
😳 What!? I'll check with the publishers...
@@ContinuousDelivery FYI: I'm in the USA, SF Bay Area, and I just purchased my copy on Amazon... $44 after taxes... I'm getting my copy tomorrow!
Just bought your book Dave, because of that smooth book promotion 😄
Thanks, I hope that you enjoy it.
If academia aren't able to prepare CS students for the workplace, then what exactly are they preparing CS students for?
grad school
Higher education tends to focus on computer science theory versus practical software engineering practices. It's less effort. It's easier to teach theory which evolves slowly versus trying to keep up with the frenetic pace of change in modern software engineering.
I think the hiring industry expects people like Dave straight out of university. That's why everyone keeps getting the wrong impression about what is required to be hire-able.
The problem is that you can miss entire paradigm shifts because you don't want to learn the current 'fad'. Reskilling from near ground 0 vs absorbing along the way can create a self-perpetuating obsolescence cycle. Take java 8; that's not just an api, it's a fundamental shift in thinking. I've interviewed folks who clearly haven't learned much after java 5 and they are basically useless now.
The trick is cherry picking things that will be helpful in the future, which is largely unknowable.
Maybe software needs a constitution, to try to take ownership of the developer experience.
Universities are just too academic and too detached from reality. They pretty much assume that you will get a PhD instead of a job.
Then you get a job and you realise almost nothing they taught you is useful at all. You need to work in a team, use tools, design and develop features for users to actually use, keep working in the same codebase for a long time and so be able to keep it maintainable with safe refactoring, track down bugs etc.
Graduates have often never even heard of writing unit tests and when you try to explain it to them they think it's a waste of time, because they are testing that the code is what the code is, rather than testing it has the desired behaviour.
But I mean I guess they know what a red-black tree is.
I think there's value in the academic system in that I think it exposes a lot of students to an environment where they have to "learn to learn" in order to succeed. Speaking solely as a product of the UK education system. It's the first time I was exposed to such an environment. It's so important that I would advise any aspiring software developer to go to university or "higher education" to this day.
But you're right, the way many courses are structured do not share the same values as actual software companies operating today. I think a mix of greenfield and brownfield projects through a software developers curriculum would be beneficial. Always moving towards collective teamwork in projects as the course progresses. What do you think?
Why he cut her off the screen when start to talk?
You should know BOTH git and SOLID :)
I live in a country where Junior Dev jobs mostly don't exist. Your a dragon slayer or your in the wrong industry.
SOLID is still important though right ? git is more of just a tool imho.
SOLID is important if job interviewer is a highly experienced software developer. If manager is doing the job interview then looking confident is more important than what you say. LOL!
@@tongobong1 absolutely i do agree... industry has more of those people who wanna hear random high impact tools and new shiny tech instead of actual pragmatic approaches to problem solving and business development. This mentality leads to over complexity and technical debt later on. Also every line of code isn't an asset but a liability lol
@@tongobong1 also i would like to add that knowing the fundamentals principles is far more important than any technology. Knowing the principles makes you understand the problem in depth and only after that you can choose the right tool to solve it.
@@aakarshan4644 the important part is also understanding the wars between different opinions about unit testing and styles, using TDD or not, agile vs waterfall... and stay away from that topics because you never know what are interviewer's preferences.
Once a manager on a job interview asked me if I am one of those that like to write unit tests - he clearly hated unit tests. Since technical lead was also present and he clearly liked unit tests I answered very diplomatically that unit tests are sometimes useful but this was not good enough answer for manager that clearly wanted to hear that I don't like unit tests... LOL
Beside can you imagine that there are many experienced developers in Europe that are still writing London style unit tests? That they still didn't realized how terrible is to mock out everything that is not a part of the class under test?
@@tongobong1 Oh man that is rough. I have no idea how to be diplomatic in tech lol, but i guess i have to keep my opinions to myself during an interview. This TDD and agile and E2E and the new one kubernetes lol. In the unit test example you wrote perhaps the best way is to just point to the timeline of the project deliverables and make a trade-off argument of interaction speed vs reliability(Unit Test). Still if some one is a fan of TDD or speed or any one approach to development its hard to convince them for your case. I heard somewhere that the best way to interview is to first read the interview him/herself and then go with the vibes lol. In the end in big tech you have enough red tape and processes that only decent+ engineering goes into production, in small to mid startups you're mostly putting out production fires lol.
thumbs down because of "you don't need SOLID, here 4 git commands", sorry