|
jot posted:A long time ago (like 10 years ago), I did some hobby programming (PHP mostly) and found it rewarding enough then. Do you think you'd still like PHP? It's still a 100% viable career choice, although you may want to look into Python/Ruby as alternatives. You could follow some tutorials online to get your skills back up to speed, and be employable very quickly. Depending on your field you might want to start looking into what sorts of certifications are en vogue. Certs suck, but if you're using PHP to do networking, you might need them. ExcessBLarg! posted:As for learning, I'd recommend an approach that mirrors (somewhat) the first two years of typical CS curriculum. I respectfully disagree. In that, what program a person needs to follow depends entirely on what field they are going to go into. And frankly, most classes do a piss-poor job of preparing students for real work. I think step one is Google as much as you can about a field you might like, to learn what tools are en vogue. Do some tutorials to get your feet wet. If you get totally stuck, then consider books / classes / whatever else you need to get up to speed. Even for the most autistic self-diagnosed person out there, self-learning should still be item number one. ullerrm posted:There's basically two major types of version control out there: (my edits) I think at this point learning programming should begin by configuring your git repository. The end of the hello world should be a git push.
|
#
?
May 18, 2015 05:02
|
|
ME
|
|
| # ? Jun 8, 2024 19:14 |
|
|
ExcessBLarg! posted:4. Find an open source project in your area of interest and make some contributions to it. Either bug fixes, or small feature enhancements, documentation, etc. There's lots of stuff that can be done here on pretty much any project. As part of "make some contributions" you'll inevitably learn about revision control, how to interact with a team, how to stage a change to be accepted by the project maintainers, etc. Keep track of your contributions (links to commits, pull requests, issues/bug reports) so that you can list them on your resume. Edit: Also as a follow up to my previous request about what you guys thought of my experience, I did apply to a well established start up and did pass their first round interview for a computer programmer with a mechanical engineering background so maybe I do know more than I think... huhu fucked around with this message at 05:15 on May 18, 2015 |
|
#
?
May 18, 2015 05:11
|
|
|
The idea that some scrub noob should go contributing to open source projects is a bit silly. Nobody really wants scrub-tier "contributions." Work on your own projects. See the screenshots thread / project.log subforum for inspiration. Maybe I just don't understand the mentality, I've only contributed to three open source projects, where one of them was my job, and the other two were small features/defect fixes that I specifically found and wanted to be fixed. I can't understand the idea of going "Oh, I'm going to make contributions to [arbitrary project I don't care about] now!" Having a hard time coming up with stuff to do? Make up poo poo to challenge yourself. Give yourself a time limit. Like, make a chess engine. You have one weekend. Make a tetris. You have one day. I had a very hard time starting anything I thought would take a while -- before this year I never spent more than 3 days working on a non-work, non-school-related project.
|
|
#
?
May 18, 2015 06:35
|
|
|
Yeah, agreed. It took me probably 4 months of working full-time at a web-dev internship before I contributed to any open-source projects, and that was just fixing small problems that I ran into while using them. I remember desperately wanting to be a better dev and reading advice columns and getting the advice to contribute to open source, but most peoples' ability to parse whole projects and contribute to them effectively is just not there until they are decently equipped. But then again I am not a wunderchild of software that was programming when I was 10 so yeah.
|
|
#
?
May 18, 2015 06:41
|
|
|
"Contribute to open source" is just too vague. The likelihood that you can check something off of the understood to-do list as babbys first project is slim. Fixing bugs on the other hand (preferably the ones that annoy you) is realistic and a practical skill. Plug-ins and add-ons that scratch an itch are also cool.
|
|
#
?
May 18, 2015 07:27
|
|
|
revdrkevind posted:There's basically two major types of version control out there: Git happens to be my favorite version control system as well. But, frankly, knowing how to use a non-distributed RCS is important, because a significant number of large companies use them. (In particular, both Google and Microsoft use heavily customized versions of Perforce.)
|
|
#
?
May 18, 2015 08:37
|
|
|
It's not important at all because when you start a job at a company that uses one, it's very easy to get up to speed unless you're mentally retarded.
|
|
#
?
May 18, 2015 08:50
|
|
|
sarehu posted:It's not important at all because when you start a job at a company that uses one, it's very easy to get up to speed unless you're mentally retarded. As a bonus to your employers, not getting up to speed *IS* a sure sign of your defect and you can be managed out.
|
|
#
?
May 18, 2015 14:28
|
|
|
Hughlander posted:As a bonus to your employers, not getting up to speed *IS* a sure sign of your defect and you can be managed out. Cf. https://www.youtube.com/watch?v=bQVc79FE5Bo&t=5s
|
|
#
?
May 18, 2015 14:55
|
|
|
revdrkevind posted:I think at this point learning programming should begin by configuring your git repository. The end of the hello world should be a git push. Eh, getting some code to compile and run is probably more important if you're really talking about starting from square one. But source control should be like, chapter 2 or 3: "Now you've written a program that says hello, it's time to add some more things to it. But wait! It would be helpful to have some way to track changes you make, especially once the code gets complicated. Blah blah blah. Source control." And then talk about the basics, saving the "working with teams" and branching strategies and wahtnot to revisit in a later chapter. But yes, leaving it out of any Getting Started With Programming type of book is kind of silly at this point.
|
|
#
?
May 18, 2015 15:40
|
|
|
Hughlander posted:managed out That is an absolutely delightful euphemism 
|
|
#
?
May 18, 2015 16:07
|
|
|
Since the best way to jinx a good thing is to count chickens before they hatch, I'm still applying while waiting on the SF place to yay/nay, and realize there's knowledge I'm lacking: how the hell do you actually sell yourself to be worth a relocation or any sort of assistance in moving cross country? Everyone says if you can write a for loop in SF you'll get a job and if you can actually explain what jump-if-equals does they'll think you float off the ground, but how do you get there? How do you get attention? Do recruiters ever hook you up if you're far away or is that only direct placement? I was contacted by the place I'm waiting to hear back from, but I can't just keep waiting on that if this doesn't work out.
|
|
#
?
May 18, 2015 16:31
|
|
|
huhu posted:Maybe I'm selling myself short and the help they need is more about a person who can put in the man hours than someone with a high level of experience? It doesn't really matter how you contribute. It can be bug fixes, documentation improvements, minor (even trivial) feature enhancements, test cases, or even just making solid bug reports. It's whatever you're comfortable with. The idea is to demonstrate that you can work in a group, with modern tools, to make a positive benefit on a project that's larger than a personal one-off. sarehu posted:The idea that some scrub noob should go contributing to open source projects is a bit silly. Nobody really wants scrub-tier "contributions." Work on your own projects. So, certainly one way to go about it is to work on your own personal (toy) project and build it on some libraries or framework or something. Work on it until you reach a point where you find some issue with one of the libraries/frameworks you're using. It might be a bug, bad documentation, or a missing feature. Search around to see if there's a solution to the problem, sometimes there is. Other times there won't be and you'll find other reports of users having similar problems but there's no movement towards resolving it. That might be a good candidate problem to tackle further. Or it might be beyond you, and you'd rather skip it which is fine. Another way to go about it is to troll an issue tracker or mailing list for a project for a while and see if there's reports about some problem that you have an interest into digging into further. The issue with presenting a portfolio consisting of just personal projects is that, while it demonstrates your (in)ability to write good code, it doesn't really give much indication of how your skills translate to working on a larger project shared by a team. Unless you're applying for a position that only deals with small projects, being able to highlight your skills in working on larger efforts demonstrates your skills in areas that many other applicants don't. ExcessBLarg! fucked around with this message at 16:38 on May 18, 2015 |
|
#
?
May 18, 2015 16:35
|
|
|
ExcessBLarg! posted:Well OK, avoid projects that regularly throw around "scrub" and "noob" and general code elitism. Yes if you avoid projects with quality standards you might do okay.
|
|
#
?
May 18, 2015 17:22
|
|
|
There's a difference between elitism and maintaining a standard of quality. I'm not suggesting that projects should have a blanket acceptance of all submission requests--in fact, that's detrimental to the learning process. But it does regularly happen that someone lobs up a useful change, and it will be critiqued and iterated on until it meets the standards and practices of the project. What's a "scrub-tier contribution" anyways?
|
|
#
?
May 18, 2015 17:48
|
|
|
ExcessBLarg! posted:What's a "scrub-tier contribution" anyways? One example would be my contribution to XMonad.
|
|
#
?
May 18, 2015 17:52
|
|
|
ExcessBLarg! posted:What's a "scrub-tier contribution" anyways? Almost everything in the kernel-janitors tree. That's why the project got reorganized/redone iirc - the focus on inclusiveness was found to be counterproductive as few of the contributors were making the jump from whitespace fixes and suchlike to meaningful contributions.
|
|
#
?
May 18, 2015 18:03
|
|
|
sarehu posted:The idea that some scrub noob should go contributing to open source projects is a bit silly. Nobody really wants scrub-tier "contributions." Work on your own projects. See the screenshots thread / project.log subforum for inspiration. Maybe I just don't understand the mentality, I've only contributed to three open source projects, where one of them was my job, and the other two were small features/defect fixes that I specifically found and wanted to be fixed. I can't understand the idea of going "Oh, I'm going to make contributions to [arbitrary project I don't care about] now!"
|
|
#
?
May 18, 2015 19:16
|
|
|
Thanks for the advice, all. I am on the fence regarding a university based program or not, but I'm one of those people that really benefits from structure in learning so I am still taking a strong look at it. Luckily, my employer has a tuition reimbursement program so I am not too concerned about the financial aspect of it - just making sure that the program I am enrolling in is a good one. Appreciate the advice regarding contributing to open source projects as well. At my skill level however, I think that I am very much a long ways away from being able to make a meaningful contribution to anything. At this point, I'm looking to re-educate myself on the fundamentals and move forward like that. I am suffering no delusions about it though - I'm prepared for the fact that it will be months/years of learning to get to where I need to be.
|
|
#
?
May 18, 2015 20:07
|
|
|
jot posted:Appreciate the advice regarding contributing to open source projects as well. At my skill level however, I think that I am very much a long ways away from being able to make a meaningful contribution to anything. At this point, I'm looking to re-educate myself on the fundamentals and move forward like that. I am suffering no delusions about it though - I'm prepared for the fact that it will be months/years of learning to get to where I need to be. Many more mature open source projects have issues open that they leave open for new and/or inexperienced contributors (which are also tagged as being good for new contributors). If you decide you want to try and contribute, those are probably a good place to start.
|
|
#
?
May 18, 2015 20:30
|
|
|
I have a phone interview with a startup tomorrow. Should I wait until a later, in-person interview to ask questions about the finances/plans of the company?
|
|
#
?
May 18, 2015 21:38
|
|
|
How fresh of a start up is it, in terms of size and age? Finances might be a bit too much unless this is like literally something in a dude's garage or if he's using the closet as his office, but concern for long-term projects or otherwise a constant stream of work is good. That's actually something I always ask in interviews, is how new projects originate.
|
|
#
?
May 18, 2015 21:54
|
|
|
revdrkevind posted:I think at this point learning programming should begin by configuring your git repository. The end of the hello world should be a git push. I would agree. College courses that I've heard about from friends (different universities than mine), and the ones I've been, in tend to cover version control in the very last class - and barely, at that. This approach is idiotic, but academia is set in its ways and rather resistant to change.
|
|
#
?
May 18, 2015 23:32
|
|
|
Yeah, I went to a CC and a university, neither taught version control. The CC did teach most sorts and searches in the very first introductory class, though. I think the Radix sort might have been introduced later. The university didn't cover proper searches and sorts until the second year.
|
|
#
?
May 18, 2015 23:47
|
|
|
At my university, we have an absolutely poo poo, totally unstandardized turnin system. It's a nightmare to deal with this stuff in between classes. I'm writing a proposal right now to use git as a turnin system, on the basis that you get to teach students version control software and a running theme throughout my proposal is "even if you use absolutely zero of the features, it's no worse than what we have now." I've been testing it lately by setting up private git repos for my own work on my account in the lab machines and it's working super well. In principle, you should be able to use hooks to enforce a lot of things (run autograder and email tentative feedback, reject late submissions, reject commits to protected files). The only thing I'm hitting a snag with is making it easy for instructors to check out the git repo for every student/group. But then, I'm also a grad student so I'm not super confident about it getting accepted. Might as well try, though! We're getting a new department head soonish so maybe change is in the air.
|
|
#
?
May 19, 2015 02:00
|
|
|
At my bootcamp (General Assembly) they handle assignment turn-in by creating a repo for the project/assignment/quiz and having each student fork/clone it and push their changes to their own repo and submit a pull request to the original. Then they comment on the pull request with feedback and close it.
|
|
#
?
May 19, 2015 02:12
|
|
|
Free revision control was pretty crummy until Git, Mercurial, and other DVCS systems came out about ten years ago. Even if CVS and Subversion were usable, the barrier of setting up a central repository put those tools out of reach for a lot of folks for use on personal projects. Of course, now with powerful, (relatively) easy to use tools, and free services like GItHub and Bitbucket, teaching revision control early is really a no brainer. But it's only really been that way for about five years now, and it takes a while for education to catch up.
|
|
#
?
May 19, 2015 02:12
|
|
|
Jsor posted:At my university, we have an absolutely poo poo, totally unstandardized turnin system. It's a nightmare to deal with this stuff in between classes. I'm writing a proposal right now to use git as a turnin system, on the basis that you get to teach students version control software and a running theme throughout my proposal is "even if you use absolutely zero of the features, it's no worse than what we have now." You could even try to get students to learn version control as a requisite course before they're taught to code. Make them fork a repo and edit Markdown files or something.
|
|
#
?
May 19, 2015 02:50
|
|
|
Stoph posted:You could even try to get students to learn version control as a requisite course before they're taught to code. Make them fork a repo and edit Markdown files or something. The main problem with this is it isn't computer science, it's software engineering. You're lucky if you get taught in a halfway marketable language, as opposed to something like Haskall. I can understand why universities want to maintain this distinction, despite the fact that almost all people who are taking computer science are in fact planning on going into software engineering. It's an industry mismatch that has yet to be corrected or a good answer found for.
|
|
#
?
May 19, 2015 03:34
|
|
|
Nobody turns 30 and thinks, "Man, I wish I learned more about version control in college."
|
|
#
?
May 19, 2015 04:00
|
|
|
Skandranon posted:The main problem with this is it isn't computer science, it's software engineering. If you draw an analogy between Computer Science and Chemistry (also a Science), then teaching how to use basic tools like shells, editors, build systems, revision control systems, etc., is equivalent to a first-year chem lab course. Both computing and chemistry can be taught and discussed purely at theoretical levels, but any well-rounded program will require some amount of hands-on experimentation and practice. There's a similar analogy that distinguishes Software Engineering and Chemical Engineering, which are more focused towards teaching industrial processes to be able to manage the production of software/chemicals at large. Edit: Maybe the point is that while revision control systems were at one time considered a heavy-weight industry tool, they're now an indispensable, basic tool for any programmer. Much of that is attributable to their lower cost of entry and modern best practices for both solo and team projects. ExcessBLarg! fucked around with this message at 04:11 on May 19, 2015 |
|
#
?
May 19, 2015 04:04
|
|
|
It's hugely different. You don't need anything but how to hit the compile button to learn programming. The next thing to learn is how to read docs (like, how to stop being a turd and just read them and write code until you figure the poo poo out instead of spending the first 4 years of your life writing conio.h programs). Version control isn't important at all.
|
|
#
?
May 19, 2015 04:09
|
|
|
sarehu posted:Nobody turns 30 and thinks, "Man, I wish I learned more about version control in college." They do if they weren't able to score a decent entry job at 21 because they weren't taught any real world skills...
|
|
#
?
May 19, 2015 04:09
|
|
|
sarehu posted:Version control isn't important at all.
|
|
#
?
May 19, 2015 04:19
|
|
|
ExcessBLarg! posted:That's not really true though. I'm not suggesting revision control is not vital for programming, but it is not a very important part of Computer Science. Computer Science doesn't even really need computers. The problem isn't that universities aren't teaching Computer Science correctly, it's that everyone is taking it and expecting it to be something that it isn't. Computer Science is like theoretical astrophysics, whereas most people want to become Mechanical Engineers. Universities should be teaching the Software Engineering that companies really would rather hire for most of their programming needs. Revision control would be a huge part of Software Engineering.
|
|
#
?
May 19, 2015 04:20
|
|
|
ExcessBLarg! posted:Revision control is hugely important as soon as you start working on a project of moderate complexity, especially one that's not a solo effort. Sure, you can technically "learn to program" without it, particularly if limiting yourself to relatively-small solo projects, but that's not really the norm and certainly not an employable skill. Tell me about it. I'm working on a ASP.NET project with a coworker and we do not have kind of source control (IT hella slow with the softwares), and it's a huge pain.
|
|
#
?
May 19, 2015 04:23
|
|
|
Skandranon posted:I'm not suggesting revision control is not vital for programming, but it is not a very important part of Computer Science. Computer Science doesn't even really need computers. The problem isn't that universities aren't teaching Computer Science correctly, it's that everyone is taking it and expecting it to be something that it isn't. Computer Science is like theoretical astrophysics, whereas most people want to become Mechanical Engineers. Universities should be teaching the Software Engineering that companies really would rather hire for most of their programming needs. Revision control would be a huge part of Software Engineering. Except "Computer Science" as you are defining it would probably be limited to algorithms, discrete math, complexity and maybe theoretical aspects of databases/structures. Like it or not, relatively few places offer degrees in Software Engineering while a lot of places offer degrees in Computer Science. And degrees should arguably conform to the expectations of the job market (even more so in the US where degrees are largely viewed as a financial investment). We could also get into a discussion about whether Software Engineering is "applied" Computer Science. The point is that CS programs already try to teach a largely applied curriculum. However most of them do a bad job at it.
|
|
#
?
May 19, 2015 04:25
|
|
|
sarehu posted:Nobody turns 30 and thinks, "Man, I wish I learned more about version control in college." Yeah... I don't understand how you can find yourself on your first job and be disappointed that you weren't taught how to use a specific tool that basically saves your work with one click/command and let's you restore it with another click/command. What is there to be taught? "This command saves, this command loads. This command puts everything where your team can see it. Done." Even if you've never seen version control before, you google the name of your tool, spend a half hour reading, and suddenly you're good to go. You're supposed to learn on the job, anyway. Are you all just disappointed that nobody told you it might be useful to be able save and reload and share your work at some point? Like that didn't seem like a thing that would be really useful after the first couple of times you ruined your homework by making a change and then saving it and then realizing you weren't sure what you did to break it and wishing you could just go back to when it was doing what you wanted it to do without having to spend an hour undoing and redoing individual combinations of changes? That said, the professor for my intro to programming class did pass out a printout with useful commands like "ls", "cd", and "javac", and "vim" and more vim-specific stuff like ":w" and ":q". I guess throwing "git add" and "git commit" onto that sheet without further explanation would have been neat, but I don't see a huge difference between teaching people how to use git and teaching people how to use vim. I would have been disappointed if we had actually received lectures on how to use a text editor. shodanjr_gr posted:They do if they weren't able to score a decent entry job at 21 because they weren't taught any real world skills... All we got about tools at my school was essentially "Tools exist for this. Find one and RTFM or just be lazy and use nano and javac for everything. It's up to you." and we turned out fine. We'd have been much worse off if we hadn't been taught to read documentation. What is there to teach about version control? It's basically three sentences: "This command saves. This command loads. This command shares." I'm serious - when you think of the ideal version control system lecture, what do you imagine the teacher saying and how much time do you imagine them taking to say it?
|
|
#
?
May 19, 2015 04:29
|
|
|
Skandranon posted:The main problem with this is it isn't computer science, it's software engineering. You're lucky if you get taught in a halfway marketable language, as opposed to something like Haskall. I can understand why universities want to maintain this distinction, despite the fact that almost all people who are taking computer science are in fact planning on going into software engineering. It's an industry mismatch that has yet to be corrected or a good answer found for. It is not really a good language to learn programming. They will spend a lot of time partly figuring out the syntax/libraries and just throwing code at a wall to see what sticks. Here I think is where things go wrong - why we end up with PHP (no offense, jot) or JS-only devs. They didn't learn programming, they learned a programming language and fiddled with it until what they wanted to do sort of happened, which those languages make much easier (as compared to C++) to do. People ought to learn programming in something that the syntax/libraries don't take months/years to learn. Instead of the above, I think if one were to start teaching programming, I would advocate starting with HTDP and some Lisp variant... Racket is a good choice. Once someone knows how to code somewhat competently, something like C++ becomes way easier to get a handle on. Evil_Greven fucked around with this message at 04:32 on May 19, 2015 |
|
#
?
May 19, 2015 04:29
|
|
|
|
| # ? Jun 8, 2024 19:14 |
|
|
Are there really people for whom it takes longer than 5 minutes and a google search to figure out version control and would actually require it be taught in school? ed: dammit Safe and Secure!
|
|
#
?
May 19, 2015 04:30
|
|
