If the implementation of up-voting, flagging, and replying/previewing is:
syntactically cleaner.
easy to extend.
then I think that would be cool to see… off of the top of my head I would just use form POST with button submit to replace some AJAX? But how would we dynamically update the DOM? Would we serve the template each time someone made a comment?
I’m having a lot of difficulty understanding why there even needs to be a post about OOP ‘sucking’. In my opinion it is evident that a lot of the world is running on systems & applications written with OOP. It’s also my opinion that a lot of those systems & applications run proficiently or else a lot of businesses and infrastructure would be in a hot mess.
Programmers, for any given problem, should just use the tools that are best suited for that given problem. FP and OOP all have their place, no need for mud slinging.
It’s also my opinion that a lot of those systems & applications run proficiently or else a lot of businesses and infrastructure would be in a hot mess.
Is it also your opinion that a lot of business code and infrastructure is not a hot mess? Because I will contend very strongly that in fact it is. (I’ve never worked anywhere it was not.)
It is my opinion that a lot of business code and infrastructure is not a hot mess, and a lot of it is a hot mess. I’m not trying to be facetious, we might end up just agreeing that there is a lot of code out there.
But I don’t have any data to validate that claim besides Github and private repos. When it comes to this ‘OOP sucks’ post, I don’t like trying to tie the hot mess some people are in with OOP for all projects ever.
As someone who is deeply invested in Angular and following these updates… At one point at work I had to let out an emotional response, and then apologize to my team for my french.
Jokes aside I accept this is the nature of our industry. I am not weary of change, I welcome it, it implies we’re growing and improving. I will accept this positive ideal over the fear of things I like changing.
IMO if you write front end code, you should have experimented with all of the relevant frameworks and made your choices based on what it enables you to do (don’t reinvent the wheel, this isn’t academics), bug support, and the programming patterns it supports. If AngularJS doesn’t provide the right tools for our team we’ll leave, it’s as simple as that.
Are any of these actually particularly common? I am graduating soon – are these behaviours I’m likely to run into in the general Silicon-Vally/software/tech company arena? (I’ve been lucky enough to work at great places for internships so far, and don’t think I’ve seen anything like these.)
It depends entirely on the company. The only real way to try and determine whether these things occur at a given company is to ask the people that work there questions to that effect. Really, the best way is to work there, but this is a solid second-place choice ;)
Questions to ask during the interview process to suss out details (by applicable question number):
2) What does the process for committing code look like? How effective is it/how often is it followed?
4) What’s your least-favorite project you’ve been on since you’ve started?
10) What kind of hardware do you develop on?
17) How well do you feel like you understand the company’s direction?
When spread out over several different interviewers (who likely aren’t communicating their specific answers between each other), you can start to get a good idea of what the people that work there really think about their company.
The interviewers probably won’t lie to you outright (would you?), but they may not tell the whole truth either. Asking a bunch of times gets you answers you can synthesize into a picture of the environment. If things sound too shady, or you can’t get a straight answer, passing on the job might be a good idea!
Edit:
Asking these kinds of questions is always a good idea, as well. Not only does it get you a good idea about the company as a whole, but it marks you as somebody who’s actually thought about the kinds of things they’d like to see in a company. From first-hand experience as an interviewer, this makes a great impression!
As someone who is working in a start up, has worked in 2 previous start ups, several months at enterprise, one tremendous personal failure, and has friends in start ups around ~10-20 people that are vocal about the problems. I will say that you will encounter at least a few of these. A company that has all of these is a company you should leave immediately without question.
If you are planning to work in this wonderful profession (no sarcasm, this is a beautiful profession with the right people) for many years, be prepared to:
Work for someone who won’t treat you the same way a recruiting document may suggest.
Work for someone who has little to no understanding of software development.
Work for someone who has little to no understanding of how to build a team.
Be in a situation where the business is struggling and stress becomes a daily thing.
Also remember as you work, you change and develop new perspectives. You will also inevitably make mistakes and see a new side to people.
Ideally you never have to deal with any of these, and you can focus on building awesome things that explore your creativity as well as the needs of people you care about.
#3 gave me flashbacks! both the ETA crap, and interrupting me to explain how I was solving the problem (for no very good reason other than the warm fuzzy illusion of managing the effort)
5 is pretty common when an exec has been sold technology before a project starts, thinking it will make everything easier. Then 5 becomes a requirement for the project or it is a) money wasted b) makes said exec look bad. The piece should be renamed to, “How Bureaucracies Function.”
Bad management is very widespread within sv / tech companies, because fast-moving companies inevitably end up with managers with little experience/training.
You can dodge some of these issues by working for larger / more-established companies, but even the most well-respected companies have bad managers thriving on some teams. Sometimes top-performing teams can be managed by complete assholes of some form or another (e.g. many of the stories about Steve Jobs).
Learning to “manage up” with inexperienced managers, or change positions when the situation is untenable is a reality of business, and not unique to tech.
Just to be clear, though – this is a managerial problem and not something you should suffer through! There are plenty of fantastic people out there to work for. As a tech worker you hold sway and can try to seek out places that don’t have these antipatterns, and work to reverse them when you see them.
Q1: if you had to start over with a blank slate, how would you go about learning?
A1: I would’ve kept it the same, but I would’ve done it with a lot more love and focus. I fell in love after a couple years of slogging and every year I spent not loving the craft is a year I regret. But I firmly believe that the moments you waste are important too, because they help you appreciate what you have that much more in hindsight and help guide you away from making bad choices.
Q2: How would you go about learning data structures?
A2: Simple data structures first, and gradually progress to more complex data structures. I would attempt to mock real world scenarios and see how certain data structures help aid you in those scenarios.
Also, you wouldn’t learn to write a paragraph before learning how to write a sentence.
Q3: How would you practice your skills?
A3: I would write a lot of code that has the intent of having a purpose without worrying about whether or not I hit the mark. And after each failure I would learn from my mistakes and try again. If this process doesn’t hurt you, you’ve definitely found something you can love and enjoy for a long time.
And honestly when I let myself have fun, I met other people who loved working hard and having fun too, and that made everything way more enjoyable. I have made a ton of mistakes, and I don’t regret a single one of them. To answer your question in the title, if I had a “redo” I would just try to make more mistakes and learn more.
Forgotten most of this stuff since learned at university. I don’t know if this means it’s not applicable in modern programming, or I’m actually not doing ‘real’ CS after all. :S
Heather Timmons: Hey! I just put together an article, I’m calling it “Alibaba has great gender diversity”
Editor: I’m going to need you to change that… can we have something like, “Alibaba and China expose that the US may be far behind Asia in Gender Equality”? nah.. That might be too sensational.. What about,
“Alibaba’s gender diversity puts Silicon Valley to shame”. I like that.
Heather Timmons: Isn’t that a bit {{ insert some you’re missing the point adjective here }}? Shouldn’t we focus the title on what Alibaba did well and how it’s exemplary of a company where both genders have strong roles in the leadership and operation of the business?
Editor: Just go with it.
Just theory-crafting, kudos to Alibaba regardless.
Development Tools: Terminal ( Pro Theme ) with some custom formatting + Sublime Text 2 and Lint/Error Checking Plugins + DiffMerge for merge conflicts + Every browser excluding Internet Explorer ( I know thats a luxury ).
Languages: Python, JavaScript ( AngularJS ), LESS & CSS
That giant 150 line switch statement must have massive mccabe score. Also not sure this class is really a type in the concept of OO. Why does a BitCoin know how to write out plain text HTM? Also the queries in a loop rankle me, but whatever. I’ve written my share of questionable code, so not really judging, just noting. ;\
I totally agree with the sentiment about writing questionable code, all great engineers have done it.
But with 700,000 BTC on the line I’m going to lean towards trying to make the code as ‘unquestionable’ as possible. That probably would’ve been a good idea. It would probably be cool to see what kind of approach Mt.Gox took towards testing.
I’m still an intermediate engineer, I should probably also leave the judging to the masters.
Implement a simple UNIX shell. Basically, for each command you have to fork, exec, and then wait for the process to finish. You’ll learn a lot about UNIX systems programming and process management.
This is a great way for people to learn about syscalls and unix in general. Once there’s a shell that can handle execution of single commands, it can be interesting to implement pipes and file redirection with dup2, or shell metacharacters like $! with the wait() syscall. Around this time it’s also a good chance to learn about zombies and orphans, and how double forking can be used to daemonize a process.
I would like to learn this! Come to think of it, I would love for a good tutorial/course in systems programming. I’ve looked around and haven’t had success in finding anything useful. If anyone has any links, please post! :)
I found working through “Advanced Programming in the Unix Environment”
(and doing the exercises) to be a good start; there’s also “The Linux
Programming Interface”. It’ll give you a good foundation.
Also, one of the things I like to do when learning a new language is to
start writing the Unix utilities in them.
I wrote a shell as the first assignment in my Operating Systems course in university. The instructions for that particular assignment are still online on the course website.
To piggyback: I think Operating Systems courses should be required in all universities teaching Computer Science, there is like a treasure chest of knowledge that is hard to grasp at first - but the rewards are so worth it.
Computer Systems: A Programmer’s Perspective, which was the reference for my University’s intro to systems class is one of the best textbooks I’ve ever read; the labs that come with it (many of which can be found on the internet) are excellent as well.
I think there will be a lot of great suggestions in this post. So I’ll just add one small practice project that taught me a lot when I was a moron (I am still a moron, sorry).
I like that post, it links to the actual paper which might be tough to read, so the stack overflow post will explain a lot to get your feet into the pond.
Do NOT look at the source code, try to think about it on a white board first. You’re doing this for yourself.
Lots of other great Suffix Tree algorithms, I personally like Farach’s linear-time suffix tree construction algorithm.
Reasons
Matching string sequences is one of the most common problems you’ll face as a programmer.
Condition your brain to think in the world of data structures.
You can time it to see how fast the computation takes, run benchmarks, much great learning! wow!
Lots of places where you can encounter pitfalls, if you decide to use C you will learn a great deal about memory management!
I write about CSS, JavaScript, Front-end, and Design
https://reading.supply/@jim
If the implementation of up-voting, flagging, and replying/previewing is:
then I think that would be cool to see… off of the top of my head I would just use form POST with button submit to replace some AJAX? But how would we dynamically update the DOM? Would we serve the template each time someone made a comment?
Without javascript you can’t dynamically update the DOM.
Users without javascript enabled would have to reload to see new comments.
I’m having a lot of difficulty understanding why there even needs to be a post about OOP ‘sucking’. In my opinion it is evident that a lot of the world is running on systems & applications written with OOP. It’s also my opinion that a lot of those systems & applications run proficiently or else a lot of businesses and infrastructure would be in a hot mess.
Programmers, for any given problem, should just use the tools that are best suited for that given problem. FP and OOP all have their place, no need for mud slinging.
Is it also your opinion that a lot of business code and infrastructure is not a hot mess? Because I will contend very strongly that in fact it is. (I’ve never worked anywhere it was not.)
It is my opinion that a lot of business code and infrastructure is not a hot mess, and a lot of it is a hot mess. I’m not trying to be facetious, we might end up just agreeing that there is a lot of code out there.
But I don’t have any data to validate that claim besides Github and private repos. When it comes to this ‘OOP sucks’ post, I don’t like trying to tie the hot mess some people are in with OOP for all projects ever.
Can anyone highlight whats wrong with Twitters current API? I haven’t used it for a while.
Just know that any suppressed feelings or emotions will come out in uglier forms in the future. Join perspectives, don’t silo yourself.
As someone who is deeply invested in Angular and following these updates… At one point at work I had to let out an emotional response, and then apologize to my team for my french.
Jokes aside I accept this is the nature of our industry. I am not weary of change, I welcome it, it implies we’re growing and improving. I will accept this positive ideal over the fear of things I like changing.
IMO if you write front end code, you should have experimented with all of the relevant frameworks and made your choices based on what it enables you to do (don’t reinvent the wheel, this isn’t academics), bug support, and the programming patterns it supports. If AngularJS doesn’t provide the right tools for our team we’ll leave, it’s as simple as that.
Are any of these actually particularly common? I am graduating soon – are these behaviours I’m likely to run into in the general Silicon-Vally/software/tech company arena? (I’ve been lucky enough to work at great places for internships so far, and don’t think I’ve seen anything like these.)
It depends entirely on the company. The only real way to try and determine whether these things occur at a given company is to ask the people that work there questions to that effect. Really, the best way is to work there, but this is a solid second-place choice ;)
Questions to ask during the interview process to suss out details (by applicable question number):
When spread out over several different interviewers (who likely aren’t communicating their specific answers between each other), you can start to get a good idea of what the people that work there really think about their company.
The interviewers probably won’t lie to you outright (would you?), but they may not tell the whole truth either. Asking a bunch of times gets you answers you can synthesize into a picture of the environment. If things sound too shady, or you can’t get a straight answer, passing on the job might be a good idea!
Edit: Asking these kinds of questions is always a good idea, as well. Not only does it get you a good idea about the company as a whole, but it marks you as somebody who’s actually thought about the kinds of things they’d like to see in a company. From first-hand experience as an interviewer, this makes a great impression!
There’s a little truth in all of them, but the ones I see most commonly are #1, #4, and #14.
As someone who is working in a start up, has worked in 2 previous start ups, several months at enterprise, one tremendous personal failure, and has friends in start ups around ~10-20 people that are vocal about the problems. I will say that you will encounter at least a few of these. A company that has all of these is a company you should leave immediately without question.
If you are planning to work in this wonderful profession (no sarcasm, this is a beautiful profession with the right people) for many years, be prepared to:
Also remember as you work, you change and develop new perspectives. You will also inevitably make mistakes and see a new side to people.
Ideally you never have to deal with any of these, and you can focus on building awesome things that explore your creativity as well as the needs of people you care about.
#3 gave me flashbacks! both the ETA crap, and interrupting me to explain how I was solving the problem (for no very good reason other than the warm fuzzy illusion of managing the effort)
At my last place, 1,5,6,9,10,19 & 21 are pretty spot on unfortunately.
That is brutal. 5 is incredibly tough to deal with. 10 is hilarious if they tell you during the interview that you can pick the hardware you want.
5 is pretty common when an exec has been sold technology before a project starts, thinking it will make everything easier. Then 5 becomes a requirement for the project or it is a) money wasted b) makes said exec look bad. The piece should be renamed to, “How Bureaucracies Function.”
Bad management is very widespread within sv / tech companies, because fast-moving companies inevitably end up with managers with little experience/training.
You can dodge some of these issues by working for larger / more-established companies, but even the most well-respected companies have bad managers thriving on some teams. Sometimes top-performing teams can be managed by complete assholes of some form or another (e.g. many of the stories about Steve Jobs).
Learning to “manage up” with inexperienced managers, or change positions when the situation is untenable is a reality of business, and not unique to tech.
Just to be clear, though – this is a managerial problem and not something you should suffer through! There are plenty of fantastic people out there to work for. As a tech worker you hold sway and can try to seek out places that don’t have these antipatterns, and work to reverse them when you see them.
Q1: if you had to start over with a blank slate, how would you go about learning?
A1: I would’ve kept it the same, but I would’ve done it with a lot more love and focus. I fell in love after a couple years of slogging and every year I spent not loving the craft is a year I regret. But I firmly believe that the moments you waste are important too, because they help you appreciate what you have that much more in hindsight and help guide you away from making bad choices.
Q2: How would you go about learning data structures?
A2: Simple data structures first, and gradually progress to more complex data structures. I would attempt to mock real world scenarios and see how certain data structures help aid you in those scenarios.
Also, you wouldn’t learn to write a paragraph before learning how to write a sentence.
Q3: How would you practice your skills?
A3: I would write a lot of code that has the intent of having a purpose without worrying about whether or not I hit the mark. And after each failure I would learn from my mistakes and try again. If this process doesn’t hurt you, you’ve definitely found something you can love and enjoy for a long time.
And honestly when I let myself have fun, I met other people who loved working hard and having fun too, and that made everything way more enjoyable. I have made a ton of mistakes, and I don’t regret a single one of them. To answer your question in the title, if I had a “redo” I would just try to make more mistakes and learn more.
Forgotten most of this stuff since learned at university. I don’t know if this means it’s not applicable in modern programming, or I’m actually not doing ‘real’ CS after all. :S
Computer Science has it’s differences from Software Engineering so I think you’re okay :)
Hypothetical Situation:
Just theory-crafting, kudos to Alibaba regardless.
Communication: Slack, E-mail, SMS
Development Tools: Terminal ( Pro Theme ) with some custom formatting + Sublime Text 2 and Lint/Error Checking Plugins + DiffMerge for merge conflicts + Every browser excluding Internet Explorer ( I know thats a luxury ).
Languages: Python, JavaScript ( AngularJS ), LESS & CSS
Database: Postgres
Products / Services: Heroku, Amazon S3, Memcached, MongoDB, Rabbitmq, Celery, Selenium
Hardware: MBP Retina with Mavericks, Hackintosh that triple boots Ubuntu, Windows 7, and OSX at home for testing, iPad, iPhone.
That giant 150 line switch statement must have massive mccabe score. Also not sure this class is really a type in the concept of OO. Why does a BitCoin know how to write out plain text HTM? Also the queries in a loop rankle me, but whatever. I’ve written my share of questionable code, so not really judging, just noting. ;\
I totally agree with the sentiment about writing questionable code, all great engineers have done it.
But with 700,000 BTC on the line I’m going to lean towards trying to make the code as ‘unquestionable’ as possible. That probably would’ve been a good idea. It would probably be cool to see what kind of approach Mt.Gox took towards testing.
I’m still an intermediate engineer, I should probably also leave the judging to the masters.
Mt. Gox was a $400M company that pushed most changes live without a testing environment.
Using God classes and plenty of mutable state makes it near impossible to unit test.
Another good idea is to implement some reasonably advanced data structure in your language of choice. Some ideas are
Wow Bloom Filter is actually a great call! Thanks for putting that on my radar again.
Implement a simple UNIX shell. Basically, for each command you have to fork, exec, and then wait for the process to finish. You’ll learn a lot about UNIX systems programming and process management.
This is a great way for people to learn about syscalls and unix in general. Once there’s a shell that can handle execution of single commands, it can be interesting to implement pipes and file redirection with dup2, or shell metacharacters like $! with the wait() syscall. Around this time it’s also a good chance to learn about zombies and orphans, and how double forking can be used to daemonize a process.
s/$!/$? :)
I would like to learn this! Come to think of it, I would love for a good tutorial/course in systems programming. I’ve looked around and haven’t had success in finding anything useful. If anyone has any links, please post! :)
I found working through “Advanced Programming in the Unix Environment” (and doing the exercises) to be a good start; there’s also “The Linux Programming Interface”. It’ll give you a good foundation.
Also, one of the things I like to do when learning a new language is to start writing the Unix utilities in them.
Advanced Linux Programming is a good reference for the different system calls you will have to use.
I wrote a shell as the first assignment in my Operating Systems course in university. The instructions for that particular assignment are still online on the course website.
To piggyback: I think Operating Systems courses should be required in all universities teaching Computer Science, there is like a treasure chest of knowledge that is hard to grasp at first - but the rewards are so worth it.
Computer Systems: A Programmer’s Perspective, which was the reference for my University’s intro to systems class is one of the best textbooks I’ve ever read; the labs that come with it (many of which can be found on the internet) are excellent as well.
I think there will be a lot of great suggestions in this post. So I’ll just add one small practice project that taught me a lot when I was a moron (I am still a moron, sorry).
Implement Ukkonen’s Suffix Tree Algorithm
Primer: http://stackoverflow.com/questions/9452701/ukkonens-suffix-tree-algorithm-in-plain-english
Notes:
I like that post, it links to the actual paper which might be tough to read, so the stack overflow post will explain a lot to get your feet into the pond.
Do NOT look at the source code, try to think about it on a white board first. You’re doing this for yourself.
Lots of other great Suffix Tree algorithms, I personally like Farach’s linear-time suffix tree construction algorithm.
Reasons
Matching string sequences is one of the most common problems you’ll face as a programmer.
Condition your brain to think in the world of data structures.
You can time it to see how fast the computation takes, run benchmarks, much great learning! wow!
Lots of places where you can encounter pitfalls, if you decide to use C you will learn a great deal about memory management!
Its fun.