I don’t really enjoy pair programming. I like pair “thinking” (if that’s a correct term). I like to think about a problem and the design space with others… but writing actual code with others doesn’t really appeal me. It’s like 2 people painting in the same canvas parts of the same picture; it’s not gonna look pretty.
I quite like "pair debugging". As someone that doesn't really like using a debugger, it's good to have someone that does use it to go through code (possibly not mine) with me commenting or suggesting problems. Probably irritates the heck out of the co-debugger though!
I was a CS student for 2 semesters at Northeastern before dropping out thanks to a job offer. No prior coding experience.
I think that the curriculum design and principles that guide the NEU CS education are fantastic. I’ve been fortunate (or unfortunate, depending on your perspective) to quickly find myself in a mentorship position at work, and there have been a number of times where I realize that the boot camp hire just isn’t thinking the way I do _at all_. The first things drilled into my head were function signatures and manipulating data structures (by implementing a subset of the ruby enumerable module in Racket). This has made problem solving by manipulating data structures (a decently common part of the job, especially at first!) genuinely trivial. Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do.
Other developers on my team though experience each new technique/thing as a new or different thing, which to me seems far more overwhelming. I think most developers naturally develop the intuition, but being told upfront “everything is just these 5 or a combination of them lol” implicitly by the work we were doing was something I’m grateful for.
I never enjoyed the pair programming at Northeastern. I was so behind my peers at the time, since most everyone else was like an AP CS student or had been coding since they were a child. I was busy trying to brute force the learning with 40+ hour weeks just for the CS fundamentals classes. I never found someone in my position. I was only paired with people that the intro course was trivial for or they just did not care at all haha. Most brutal part was waiting 5+ hours at office hours with a white board wait list 90+ names deep and then office hours would end and they would send us home. Life before ChatGPT was crazy.
From the linked article : "How to Design Programs is the first text book on programming that explicitly spells out how to construct programs in a systematic manner."
You didn't explain how the "bootcamp grads" thought process differs from yours.
> Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do
It comes across as smug. "How dare these bootcamp grads write a for loop when I am wrangling a complex reduce expression."
Even thought that may not be what you meant.
Probably why people even around here find the PLT nerds obnoxious.
whatever you described is often not the hard part of the code at $dayjob.
Also for most people database dictates the choice of data structure and algorithm.
CS is not complete without compilers, networks, DBs, OSes and computer architecture. Yet somehow PLT nerds pretend they unlocked a super power with map and reduce.
This is an interesting article. I do appreciate the focus on pair programming, which is probably something that's really helped me improve as a programmer, and their process seems quite interesting.
It would be interesting to see this method actually works, i.e. if Northeastern programmers are "more useful to their employers"/"better developers" than graduates of Universities using the older approach ('tinker until it works', as the featured article puts it)
If I was trying to develop good developers, I'd add a 7th initial, recurring step to the vertical: Talk to your customer as often and directly as possible to ensure you are still working on the right problem.
It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about. Not that this is necessarily bad (hobby, fun, art, side projects, new ideas, etc), but in a concrete business setting you need to be a bit more aggressive about making sure the customer still gives a shit about what you are working on over time.
I find all of this leads neatly into the 2nd most important thing for me which is making sure you have a good domain model (schema). If the tables, columns and relations that represent the business are high quality and accurate (I.e., your customer understands them), the code that follows will usually go smoothly. Staying on the customer's heels regarding the applicability of your software to the business means you can keep this well aligned over time.
I think much of the tech bloat we see today is a side effect of attempting to outrun the complexity of the customer's specific needs. After sitting on the phone with vendors and customers for a week, you will likely not find yourself playing around with the idea of using some esoteric language or infra to implement things. It's incredible what being directly exposed to the customers can do for a developer's growth.
It’s completely true. Sometimes software development is at the crossroads of art and craftsmanship. So we like to do things nicely for the sake/pleasure of it and we can loose sight of what really matters. Most of the times, what really matters is the customer using the product and if the product is a tool, the most important criterias for him have to be aligned to what we spent the most time on. Sometimes we want to make a generic case out of specific ones in order for all customers to also benefit from it and that can lead us to higher, unnecessary levels of abstraction and sometimes because there isn’t enough it leads to hard to maintain spaghetti code that is working under specific conditions that are hard to evolve. The balance is thin and often blurry because it’s a bet on an uncertain future that depends on how well we can predict future business
> It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about.
That's where classic software methodologies such as Waterfall are good at: everything must be carefully discussed with the customer during the "requirements analysis" phase.
I don’t really enjoy pair programming. I like pair “thinking” (if that’s a correct term). I like to think about a problem and the design space with others… but writing actual code with others doesn’t really appeal me. It’s like 2 people painting in the same canvas parts of the same picture; it’s not gonna look pretty.
I quite like "pair debugging". As someone that doesn't really like using a debugger, it's good to have someone that does use it to go through code (possibly not mine) with me commenting or suggesting problems. Probably irritates the heck out of the co-debugger though!
I completely agree.
I was a CS student for 2 semesters at Northeastern before dropping out thanks to a job offer. No prior coding experience.
I think that the curriculum design and principles that guide the NEU CS education are fantastic. I’ve been fortunate (or unfortunate, depending on your perspective) to quickly find myself in a mentorship position at work, and there have been a number of times where I realize that the boot camp hire just isn’t thinking the way I do _at all_. The first things drilled into my head were function signatures and manipulating data structures (by implementing a subset of the ruby enumerable module in Racket). This has made problem solving by manipulating data structures (a decently common part of the job, especially at first!) genuinely trivial. Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do.
Other developers on my team though experience each new technique/thing as a new or different thing, which to me seems far more overwhelming. I think most developers naturally develop the intuition, but being told upfront “everything is just these 5 or a combination of them lol” implicitly by the work we were doing was something I’m grateful for.
I never enjoyed the pair programming at Northeastern. I was so behind my peers at the time, since most everyone else was like an AP CS student or had been coding since they were a child. I was busy trying to brute force the learning with 40+ hour weeks just for the CS fundamentals classes. I never found someone in my position. I was only paired with people that the intro course was trivial for or they just did not care at all haha. Most brutal part was waiting 5+ hours at office hours with a white board wait list 90+ names deep and then office hours would end and they would send us home. Life before ChatGPT was crazy.
Are there any books that discuss this technique?
It's the philosophy behind How to Design Programs (https://htdp.org/) and Matthias' other educational works. On HtDP might be relevant to your interests (https://felleisen.org/matthias/OnHtDP/index.html)
From the linked article : "How to Design Programs is the first text book on programming that explicitly spells out how to construct programs in a systematic manner."
You didn't explain how the "bootcamp grads" thought process differs from yours.
> Things more or less immediately translate to a map, filter, andmap, ormap, or reduce when trying to get data from its input to its output for whatever unit of work I’m trying to do
It comes across as smug. "How dare these bootcamp grads write a for loop when I am wrangling a complex reduce expression."
Even thought that may not be what you meant.
Probably why people even around here find the PLT nerds obnoxious.
whatever you described is often not the hard part of the code at $dayjob.
Also for most people database dictates the choice of data structure and algorithm.
CS is not complete without compilers, networks, DBs, OSes and computer architecture. Yet somehow PLT nerds pretend they unlocked a super power with map and reduce.
This is an interesting article. I do appreciate the focus on pair programming, which is probably something that's really helped me improve as a programmer, and their process seems quite interesting.
It would be interesting to see this method actually works, i.e. if Northeastern programmers are "more useful to their employers"/"better developers" than graduates of Universities using the older approach ('tinker until it works', as the featured article puts it)
If I was trying to develop good developers, I'd add a 7th initial, recurring step to the vertical: Talk to your customer as often and directly as possible to ensure you are still working on the right problem.
It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about. Not that this is necessarily bad (hobby, fun, art, side projects, new ideas, etc), but in a concrete business setting you need to be a bit more aggressive about making sure the customer still gives a shit about what you are working on over time.
I find all of this leads neatly into the 2nd most important thing for me which is making sure you have a good domain model (schema). If the tables, columns and relations that represent the business are high quality and accurate (I.e., your customer understands them), the code that follows will usually go smoothly. Staying on the customer's heels regarding the applicability of your software to the business means you can keep this well aligned over time.
I think much of the tech bloat we see today is a side effect of attempting to outrun the complexity of the customer's specific needs. After sitting on the phone with vendors and customers for a week, you will likely not find yourself playing around with the idea of using some esoteric language or infra to implement things. It's incredible what being directly exposed to the customers can do for a developer's growth.
It’s completely true. Sometimes software development is at the crossroads of art and craftsmanship. So we like to do things nicely for the sake/pleasure of it and we can loose sight of what really matters. Most of the times, what really matters is the customer using the product and if the product is a tool, the most important criterias for him have to be aligned to what we spent the most time on. Sometimes we want to make a generic case out of specific ones in order for all customers to also benefit from it and that can lead us to higher, unnecessary levels of abstraction and sometimes because there isn’t enough it leads to hard to maintain spaghetti code that is working under specific conditions that are hard to evolve. The balance is thin and often blurry because it’s a bet on an uncertain future that depends on how well we can predict future business
> It seems to me that a lot of wasted energy is in the form of working on problems that no one cares about.
That's where classic software methodologies such as Waterfall are good at: everything must be carefully discussed with the customer during the "requirements analysis" phase.
What are the more modern methodologies?
Scrum, which means letting a clueless "scrum master" and "product owner" change directions twice a week so they can pretend to be working.