I think this advice is given in the right spirit, but is potentially completely wrong.
I agree that it's extremely important to work in high-performing teams, or at least teams that are really good at something. That's true whether you're new or not, since by definition the team of which you are a member will have more aggregate impact than you will.
But working alone is critically important for all the pieces of the development process that aren't technical. Learning to represent yourself and your ideas, execute on the effectively, and drive them to completion without help-- those are the skills which will consistently produce success and whose lack will consistently produce failure. And IMO, you only really learn them when you're on your own and in the crunch.
So if you feel like you have those skills, seek collaboration and the wisdom of crowds. If you don't, I think you're better off seeking challenge and the risk that comes with it.
The blog is explicitly aimed at new developers. For them, I think working alone is a really tough spot, because they're going to have a hard time learning on their own, they won't have anyone to bounce ideas off of regularly, and they won't have someone at work to mentor them.
For developers later in their career, I think your advice is spot on. I remember lying on the ground struggling to solve one of the hardest problems I've ever tried to solve (as co-founder of a startup) and I'm proud of that solution. Having someone there would have helped, but wasn't required and probably wouldn't have helped me grow as much.
To be honest, when people ask me where I got my abilities in researching diverse subjects and tracking down obscure faults from, the only thing I can really tell them is that I never really had anyone to turn to when I was learning - I had to just find a way to make it work. Couldn't defer "the hard stuff" to someone else. I think working alone gained me quite a lot.
> But working alone is critically important for all the pieces of the development process that aren't technical.
Sure, but good engineering happens with closed feedback loops. Even if you learn to check your own assumptions, users still need to be informed, documentation improved, subsystems integrated, new platforms supported.
Good engineering is a team sport.
So maybe you can turn a confusing stack trace into a patch on your own. Great. Tru success happens when you ship. And shipping to yourself is rarely interesting.
I think you misunderstand what "working alone" means.
In one context, it could mean being the solo developer on a project. In another context, it means avoiding what some people call "pair programming."
This article clearly implies that a new developer should be part of a team. It never alludes to pair programming.
Why is being a member of a team important for a first developer job? There's a lot of things left out of a typical Computer Science degree that are needed to be an effective programmer. Being a member of a team is the easiest way to learn these things.
(For example, we never discussed source code control in my school, or why someone would deliberately denormalize a SQL database.)
> But working alone is critically important for all the pieces of the development process that aren't technical
I would actually argue the opposite. Work with someone more experienced on the non-technical parts and do the technical alone.
Finding online resources for technical problems is easier in my opinion. But for non-technical you're probably going to need domain knowledge or just plain experience to complete and getting those are so much simpler when seeing examples of it from others
I've always learned more from books and the Internet as well as just trying to figure things out for myself than from colleagues, despite having worked with some very smart people. I have learned some valuable things from coworkers but if I had to pick just one there's really no contest. I can also think of many occasions where taking what a coworker told me at face value without doing some independent research myself would have led me to learn bad practices or outright falsehoods.
This might depend on the individual but without seeing some empirical evidence I'm not convinced that this advice is that useful.
One advantage of working alone is that you will inevitably be closer to the business, its product, and its users. To me that has been worth more than working with a high performing development team. I am not in a US tech center, my road to decent compensation is not being a brilliant technician in high paying companies.
I do notice in technical arguments on the internet I often seem to come out of leftfield. It took me a while to realise it was because people in larger teams have an entirely different perspective when it comes to tools and technology. I need a Toyota and they need an Airbus.
The interesting thing about our industry is that give it 10 years and your Toyota will get you and 150 of your friends from LA to NYC in 5 hours.
If you stuck with Rails and Postgres for the past 10 years, your “solution power” has probably expanded nearly 10x due to improvements in the hardware and software ecosystems. That’s just one example - pick your stack and the statement probably applies.
> I suggest that the first job you take be the one with the highest learning potential, not the highest earning potential
I don't know about the advice to take the job where you learn the most. It's great advice for startup founders and company owners who can get naive young new graduates for below market rates. Not so great for the graduates themselves.
See, jobs that pay a lot are typically demanding of your intellect. You're going to need to learn a lot to do them well. But beyond that, you have limited time on this Earth. If you've decided you're going to trade some of it away for money, it seems wise to make sure you're getting as much back in exchange as you can, other things being equal.
I've known a number of people who did the naive, idealistic thing and worked for a string of startups in their twenties and early thirties. But, inevitably, most of those companies end up failing -- that's the most common situation -- or paying out what amounts to a nice bonus after years of high risk, high stress, labor paid below market rates. BTW, that second scenario is the 99% best case scenario.
Sure, if you're this person, you've had some exciting times. But you didn't own those times. Those were the founders. You were just working for the owner. And now you've finally wised up, but you're ten to fifteen years behind the ball on saving for retirement or a house.
A lot of young people really can't understand how big of a problem it can be to just be getting started on this stuff in your late thirties. It seems like you have all the time in the world, but you really don't. Fortunately, in software engineering, we're paid so well that a frugal person can do a lot of catching up. But if things don't go nominally, shit can get rough.
Just throwing this out there. I think the "work to learn" advice is idealistic, but I don't think it necessarily serves every potential recipient. Or even most of them. If you don't have family money to fall back on, consider putting on your life vest by putting in a few years getting paid as much as you can, then consider whether there's something that's missing from your career that could be served by taking the high risk, learning-focused job. Or, just jump right into founding companies. But don't work for below-market rates and a tenth of a percent for a startup founder who probably has a trust fund.
> I don't know about the advice to take the job where you learn the most. It's great advice for startup founders and company owners who can get naive young new graduates for below market rates. Not so great for the graduates themselves.
Well, everyone is entitled to their opinion.
For what it is worth I don't think a startup (or, for that matter, any place that treats you poorly) is the best place for a new developer. Having been part of a couple of startups, I don't know if they are the best place to learn (especially for new developers). Often, chaos reigns, it's hard to get direction, and stuff is often on fire. Not an optimal learning environment.
This varies for different risk profiles, learning styles and long term career desires, but if forced to choose I'd probably pick a small consulting company as the place where you'd learn the most. (BTW, you'd probably get paid decently as well, since there'd be no options at the end of the rainbow.)
I truly think it does. You will usually raise your salary most by changing jobs anyway and when you start out you most likely don't have that much need of a high salary.
A start up might absolutely not be the right way to learn though. Joining a mature and disciplined engineering organization might instead be a much better choice for learning.
The world is full of people trapped doing meaningless robotic things as it is. On top of it they are all living longer wondering what the fuck for. Just ask a friendly neighbourhood shrink for the stats.
Your kind of advice my friend contributes to the trap.
I think Steve Jobs said the only way to be great at what you do is to do what you love. And I would add the only way to really amp up your income is to be as great as you possibly can be at what you do, and always look to be better.
I had a couple jobs I took mainly for the money. They were soul-deadening. Maybe some people can handle that, but for me it's a recipe for burnout.
The interesting thing is I made, by far, the most money running my own company and doing work I actually enjoyed.
I think this advice is cutting your nose off to spite your face. I took my first job to learn. I was underpaid, and over worked. But I got to work on all sorts of stuff I wouldn’t have otherwise been able to touch for years, I learned a ridiculous amount, and when I left that job I took an enormous leap in salary. Since then I’ve managed to keep it going up and a very steady pace. Advising against such working conditions in general is narrow minded and short sighted. That company got a huge amount of value out of me, and they didn’t pay a fair salary for it. But in place of that salary, I got a huge amount of value out of them. My goal (especially at the time) wasn’t to get the fairest market rate, it was to increase my market value as much as possible. A goal I achieved, which has meant I’m now out earning most of my peers, and I generally have much more control over my working conditions than they do.
I agree with you that it's not a good idea to pull overtime or work high stress positions for little compensation.
However i don't think that the only place where you can learn is at a startup. On the contrary, i think there is a lot more opportunity for learning at larger companies.
You would have to be very lucky to find a startup with devs that are both good and have the free time to mentor you well. But in a FAANG or a similar company in the second or third tier, you will be working with a lot of smart people who have both the time and a career interest in helping you grow.
Personally i am ambivalent on the value of wealth as an end in itself. For people who value knowledge as an end in itself, i do think it's reasonable career advice to deliberately seek out a company where they can get that support from their peers. It definitely makes going to work to earn the money every day less of a chore.
When I finished high school I interviewed for a couple of programmer jobs and was offered both. One was a spot on a technical team which paid quite little, the other was a role where I would be the sole technical person which paid much more. I took the former job without much deliberation, and it turned out to be one of the best decisions I have made.
When you’re new to the field it’s better to work with others than alone. Even if the others are terrible at their jobs, you can learn a lot about what not to do.
I'm not sure about this. It might be best for some but not for others. The most I ever learned was on a train wreck of a project where management decided to do a large rewrite compounded with redesigns and growing scope. I was the sole Android dev replacing a team of contractors. The only good thing about the turmoil was how many chances I had to iterate on things and redo them from scratch trying new patterns. I was the only dev but the product, design and QA teams reviewed the results of my work. It meant I could be courageous in my engineering changes but still grounded by product reality.
I wouldn't recommend this as a way to do business but being paid to crank out feature verticals only to throw them away and start over was a big learning experience.
I've also had experiences more inline with the article as well but it's not the only way to learn and might not be the best even if it's a common, low risk way to learn.
To truly succeed as developer, you need feedback, I mean team and actionable feedback: code reviews, stand-ups, design doc reviews, etc. When you are able to explain your ideas to a group most of the time you grow, as you need to make sure you are doing your due diligence when you present your work.
Quote: "Dear new developer,
I suggest that the first job [...] even if they are new as well, will elevate you."
Hell no! This is wrong and I've seen it plenty of times. Dear new developer, go glue yourself to a senior one, make him your mentor and you'll learn a lot. Also a team of only new ones tend to rely on stackoverflow and will result in bad practices in the end.
Dear new developer, avoid teams where you have no mentor to learn from. Also, while you're around your mentor, don't pester him before you applied "the rubber duck" technique on your question/problem.
I suggest that the first job you take be the one with the highest learning potential, not the highest earning potential.
The only reason anyone works under another in this modern system is for money. Anyone who claims otherwise is stupid or lying. I'm forced to consider the motivation for giving this advice to new blood looking for employment and it's obvious.
I work alone and I've learned a great deal with only books; note I mean work and not employment, here. Building empathy in the context of employment is only useful for promotions or continuing employment and I disagree with this notion that every programmer must, for some reason, become more empathetic, usually meaning capitulating to certain others, as if all programmers are lacking empathy.
As for your advice to join an online community, it's not bad on its face, but the particulars could be improved, I think. An IRC channel is a good choice; Reddit or Hacker News aren't; those two, in particular, are only useful for self-promotion, as they mostly discuss things happening elsewhere and only even that briefly; conversations don't last months or years in these places; they're unsuited to discussions not based around self-promotion, for the most part; the goal is to have one's link on the front index or collect Internet points, generally. The only reason I have an account here is to promote my work, and I've had some success.
As for an Internet community and making mistakes, you'll feel no shame if you simply use an anonymous form of communication. Imageboards are good examples. You can ask a silly question or make a mistaken claim and you don't suffer social stigma, because there's no identity to start with.
You're not cold blooded like a shark. You're a frozen rock.
There are many reasons to be an employee. Prestige, social connections, stability, interest, passion, learning and more.
Empathy is not a form of capitulation. Solipsism can be a detrimental.
You talk mad game about what your purpose is posting here, self promotion and all that, but your post is both contrary to that goal and has it's own story.
Even on imageboards you have an identity. You just don't have particular kinds of consequences. Stay off them, they aren't your social skills crutch.
These are all great advices, but very hard to act on. I got hired by one of the big silicon Valley consultencies with the promise of working in teams and great personal development. Had I been there an entire year, I would have worked completely on my own for 9 months. After voicing my concerns for several months I decided to leave.
I think you acted on the advice as best as you could. I mean, I'm guessing you asked about your work environment (or were told).
If there is a bait and switch, all you can do is voice your concerns and if you aren't heard, leave. Which you did. About the only other thing you can do is share your experience, either publicly or via your network (the latter of which I strongly encourage you to do).
There's definitely an asymmetry of power between employer and employee--everyone has at most 1-2 jobs but employers have many employees.
I have worked alone almost exclusively, and the few times I have got to work with a more experienced consultant I learned career changing skills. I’m probably at the halfway mark for my career, but seeing how much easier it is to learn when it isn’t me bymyself wiTh whatever book I think will be helpful has definitely made me realize the opportunity cost of being remote and having no senior or more experienced coworkers. Probably having no more experienced coworkers was a big contributor to going remote, I wasn’t going to miss anything at the office except climbing the ladder to managemenT, which actually would have been sweet cause who wants to be slanging code and minding machines at 50, the people problems are so much more interesting and applicable to everyday life
This is pretty bad advice. Any workplace will have a fixed way of doing things that are suitable for their legacy code and existing practices. Not to mention most places don't really let you extend over to other areas. There's a big difference between dabbling in some aspect of development as part of a job and handling it yourself from start to finish on your own.
Some of my biggest growths as a developer has been doing things on my own that businesses aren't going to pay someone to look into.
I have worked in teams and hated it, my son is a new developer and he loves working in teams.
My most disturbing experiences have been with "agile" and my better experiences have been with "pair programming".
Quality of code is a problem in code generated by agile teams. Unnecessary time pressure
The best written code I found to have been written by a single developer given the freedom to express themselves.
This is my opinion based on personal experience
"...understanding others and building empathy..." agreed this is good. I hate to sound like a cynic but it often seems like understanding others and building empathy is the fast track to nowhere. Almost any software shop is going to be a business, and in a business usually the most essential skill is a paranoid un-empathizing mastery of high school politics.
I agree with the part that it's very good if a new developer gets to work with an amazing team. Thus us probably not mutually exclusive with earning potential either.
Best people do tend to end up in places where they get paid well. Obviously this may not be always true, but your chances are good if you join a high performing team both in terms of learning and earning.
We don't work alone. We use tools for collaboration as we're generally part of a team. Whether that team is remote, geo-located or all in the same open office, they all have their pros and cons. Design always requires a whiteboard so on-prem is best. Writing the raw code is best done heads down.
[+] [-] debatem1|6 years ago|reply
I agree that it's extremely important to work in high-performing teams, or at least teams that are really good at something. That's true whether you're new or not, since by definition the team of which you are a member will have more aggregate impact than you will.
But working alone is critically important for all the pieces of the development process that aren't technical. Learning to represent yourself and your ideas, execute on the effectively, and drive them to completion without help-- those are the skills which will consistently produce success and whose lack will consistently produce failure. And IMO, you only really learn them when you're on your own and in the crunch.
So if you feel like you have those skills, seek collaboration and the wisdom of crowds. If you don't, I think you're better off seeking challenge and the risk that comes with it.
[+] [-] mooreds|6 years ago|reply
The blog is explicitly aimed at new developers. For them, I think working alone is a really tough spot, because they're going to have a hard time learning on their own, they won't have anyone to bounce ideas off of regularly, and they won't have someone at work to mentor them.
For developers later in their career, I think your advice is spot on. I remember lying on the ground struggling to solve one of the hardest problems I've ever tried to solve (as co-founder of a startup) and I'm proud of that solution. Having someone there would have helped, but wasn't required and probably wouldn't have helped me grow as much.
[+] [-] ris|6 years ago|reply
[+] [-] humanrebar|6 years ago|reply
Sure, but good engineering happens with closed feedback loops. Even if you learn to check your own assumptions, users still need to be informed, documentation improved, subsystems integrated, new platforms supported.
Good engineering is a team sport.
So maybe you can turn a confusing stack trace into a patch on your own. Great. Tru success happens when you ship. And shipping to yourself is rarely interesting.
[+] [-] gwbas1c|6 years ago|reply
In one context, it could mean being the solo developer on a project. In another context, it means avoiding what some people call "pair programming."
This article clearly implies that a new developer should be part of a team. It never alludes to pair programming.
Why is being a member of a team important for a first developer job? There's a lot of things left out of a typical Computer Science degree that are needed to be an effective programmer. Being a member of a team is the easiest way to learn these things.
(For example, we never discussed source code control in my school, or why someone would deliberately denormalize a SQL database.)
[+] [-] janee|6 years ago|reply
I would actually argue the opposite. Work with someone more experienced on the non-technical parts and do the technical alone.
Finding online resources for technical problems is easier in my opinion. But for non-technical you're probably going to need domain knowledge or just plain experience to complete and getting those are so much simpler when seeing examples of it from others
[+] [-] mattnewport|6 years ago|reply
This might depend on the individual but without seeing some empirical evidence I'm not convinced that this advice is that useful.
[+] [-] lacampbell|6 years ago|reply
I do notice in technical arguments on the internet I often seem to come out of leftfield. It took me a while to realise it was because people in larger teams have an entirely different perspective when it comes to tools and technology. I need a Toyota and they need an Airbus.
[+] [-] pbourke|6 years ago|reply
This is a great point - “horses for courses.”
The interesting thing about our industry is that give it 10 years and your Toyota will get you and 150 of your friends from LA to NYC in 5 hours.
If you stuck with Rails and Postgres for the past 10 years, your “solution power” has probably expanded nearly 10x due to improvements in the hardware and software ecosystems. That’s just one example - pick your stack and the statement probably applies.
[+] [-] asdfasgasdgasdg|6 years ago|reply
I don't know about the advice to take the job where you learn the most. It's great advice for startup founders and company owners who can get naive young new graduates for below market rates. Not so great for the graduates themselves.
See, jobs that pay a lot are typically demanding of your intellect. You're going to need to learn a lot to do them well. But beyond that, you have limited time on this Earth. If you've decided you're going to trade some of it away for money, it seems wise to make sure you're getting as much back in exchange as you can, other things being equal.
I've known a number of people who did the naive, idealistic thing and worked for a string of startups in their twenties and early thirties. But, inevitably, most of those companies end up failing -- that's the most common situation -- or paying out what amounts to a nice bonus after years of high risk, high stress, labor paid below market rates. BTW, that second scenario is the 99% best case scenario.
Sure, if you're this person, you've had some exciting times. But you didn't own those times. Those were the founders. You were just working for the owner. And now you've finally wised up, but you're ten to fifteen years behind the ball on saving for retirement or a house.
A lot of young people really can't understand how big of a problem it can be to just be getting started on this stuff in your late thirties. It seems like you have all the time in the world, but you really don't. Fortunately, in software engineering, we're paid so well that a frugal person can do a lot of catching up. But if things don't go nominally, shit can get rough.
Just throwing this out there. I think the "work to learn" advice is idealistic, but I don't think it necessarily serves every potential recipient. Or even most of them. If you don't have family money to fall back on, consider putting on your life vest by putting in a few years getting paid as much as you can, then consider whether there's something that's missing from your career that could be served by taking the high risk, learning-focused job. Or, just jump right into founding companies. But don't work for below-market rates and a tenth of a percent for a startup founder who probably has a trust fund.
[+] [-] mooreds|6 years ago|reply
Well, everyone is entitled to their opinion.
For what it is worth I don't think a startup (or, for that matter, any place that treats you poorly) is the best place for a new developer. Having been part of a couple of startups, I don't know if they are the best place to learn (especially for new developers). Often, chaos reigns, it's hard to get direction, and stuff is often on fire. Not an optimal learning environment.
This varies for different risk profiles, learning styles and long term career desires, but if forced to choose I'd probably pick a small consulting company as the place where you'd learn the most. (BTW, you'd probably get paid decently as well, since there'd be no options at the end of the rainbow.)
I actually wrote about this here:
https://www.culturefoundry.com/cultivate/digital-agency-life... That said, my advice is anecdotal and based not on science or statistics, but on my experience. So it may not be worth much more than you paid for it.
[+] [-] cc81|6 years ago|reply
A start up might absolutely not be the right way to learn though. Joining a mature and disciplined engineering organization might instead be a much better choice for learning.
[+] [-] hos234|6 years ago|reply
Your kind of advice my friend contributes to the trap.
[+] [-] thothamon|6 years ago|reply
I had a couple jobs I took mainly for the money. They were soul-deadening. Maybe some people can handle that, but for me it's a recipe for burnout.
The interesting thing is I made, by far, the most money running my own company and doing work I actually enjoyed.
[+] [-] AmericanChopper|6 years ago|reply
[+] [-] alisonatwork|6 years ago|reply
However i don't think that the only place where you can learn is at a startup. On the contrary, i think there is a lot more opportunity for learning at larger companies.
You would have to be very lucky to find a startup with devs that are both good and have the free time to mentor you well. But in a FAANG or a similar company in the second or third tier, you will be working with a lot of smart people who have both the time and a career interest in helping you grow.
Personally i am ambivalent on the value of wealth as an end in itself. For people who value knowledge as an end in itself, i do think it's reasonable career advice to deliberately seek out a company where they can get that support from their peers. It definitely makes going to work to earn the money every day less of a chore.
[+] [-] enneff|6 years ago|reply
When you’re new to the field it’s better to work with others than alone. Even if the others are terrible at their jobs, you can learn a lot about what not to do.
[+] [-] jayd16|6 years ago|reply
I wouldn't recommend this as a way to do business but being paid to crank out feature verticals only to throw them away and start over was a big learning experience.
I've also had experiences more inline with the article as well but it's not the only way to learn and might not be the best even if it's a common, low risk way to learn.
[+] [-] spicyramen|6 years ago|reply
[+] [-] unnouinceput|6 years ago|reply
Hell no! This is wrong and I've seen it plenty of times. Dear new developer, go glue yourself to a senior one, make him your mentor and you'll learn a lot. Also a team of only new ones tend to rely on stackoverflow and will result in bad practices in the end. Dear new developer, avoid teams where you have no mentor to learn from. Also, while you're around your mentor, don't pester him before you applied "the rubber duck" technique on your question/problem.
[+] [-] thrower123|6 years ago|reply
[+] [-] verisimilitudes|6 years ago|reply
I suggest that the first job you take be the one with the highest learning potential, not the highest earning potential.
The only reason anyone works under another in this modern system is for money. Anyone who claims otherwise is stupid or lying. I'm forced to consider the motivation for giving this advice to new blood looking for employment and it's obvious.
I work alone and I've learned a great deal with only books; note I mean work and not employment, here. Building empathy in the context of employment is only useful for promotions or continuing employment and I disagree with this notion that every programmer must, for some reason, become more empathetic, usually meaning capitulating to certain others, as if all programmers are lacking empathy.
As for your advice to join an online community, it's not bad on its face, but the particulars could be improved, I think. An IRC channel is a good choice; Reddit or Hacker News aren't; those two, in particular, are only useful for self-promotion, as they mostly discuss things happening elsewhere and only even that briefly; conversations don't last months or years in these places; they're unsuited to discussions not based around self-promotion, for the most part; the goal is to have one's link on the front index or collect Internet points, generally. The only reason I have an account here is to promote my work, and I've had some success.
As for an Internet community and making mistakes, you'll feel no shame if you simply use an anonymous form of communication. Imageboards are good examples. You can ask a silly question or make a mistaken claim and you don't suffer social stigma, because there's no identity to start with.
[+] [-] friendlybus|6 years ago|reply
There are many reasons to be an employee. Prestige, social connections, stability, interest, passion, learning and more.
Empathy is not a form of capitulation. Solipsism can be a detrimental.
You talk mad game about what your purpose is posting here, self promotion and all that, but your post is both contrary to that goal and has it's own story.
Even on imageboards you have an identity. You just don't have particular kinds of consequences. Stay off them, they aren't your social skills crutch.
[+] [-] Throwaway8373|6 years ago|reply
[+] [-] mooreds|6 years ago|reply
If there is a bait and switch, all you can do is voice your concerns and if you aren't heard, leave. Which you did. About the only other thing you can do is share your experience, either publicly or via your network (the latter of which I strongly encourage you to do).
There's definitely an asymmetry of power between employer and employee--everyone has at most 1-2 jobs but employers have many employees.
[+] [-] generatorguy|6 years ago|reply
[+] [-] Ididntdothis|6 years ago|reply
From my experience these are highly correlated.
[+] [-] preommr|6 years ago|reply
Some of my biggest growths as a developer has been doing things on my own that businesses aren't going to pay someone to look into.
[+] [-] naasking|6 years ago|reply
I think you're seriously undervaluing how much new devs can learning from exactly this. This article is targeted at new devs.
[+] [-] peter_retief|6 years ago|reply
Quality of code is a problem in code generated by agile teams. Unnecessary time pressure
The best written code I found to have been written by a single developer given the freedom to express themselves. This is my opinion based on personal experience
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] purplezooey|6 years ago|reply
[+] [-] smadurange|6 years ago|reply
Best people do tend to end up in places where they get paid well. Obviously this may not be always true, but your chances are good if you join a high performing team both in terms of learning and earning.
[+] [-] sys_64738|6 years ago|reply
[+] [-] toolslive|6 years ago|reply