Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Reelya]

Better: find some legit open source projects to work on.

[Rose]

I did that part, but haven't managed the 'using it to get a job' part.

[Shub-Nullgurath]

Does anyone here have experience with programming professionally? As in you are hired and paid money to write code or other computer science stuff?

I'm taking college courses and getting a degree in compsci, but I really doubt college courses alone are enough prep for competing in the job market. I feel like I don't really know what I'm getting into. Can anyone describe what their work is like, or what the average tasks in a work day would be, or what your employer was looking for when hiring you? I'd like to have a better idea of what I'm actually supposed to be doing in real world applications, not a college environment.

I've taken a year out of university to do Embedded Development for a company. I applied to a bunch of jobs that didn't require me to fill out any forms (just send off CV), went to two interviews and eventually got this position. I had a few places hounding me shortly after I got this job but none of them were quite as good as this one.

Day to day, I just work on my current project. Occasionally I'll get given a few bits and pieces to do in old software but that's mostly a hassle to get the stuff installed (a week or two ago, I had to install VB6 to work on one of our old projects). We have weekly progress meetings.

In the UK, as long as you have experience and / or a degree in something related to programming, you can essentially walk from one job to another. I've heard the situation is better in the US (the pay is certainly better post-Brexit).

The point of Git and stuff like that is a sweetener for your CV and career. It's to show you program outside of work and to showcase what you can do.

[miauw62]

open source is a great learning experience if nothing else.

[da_nang]

If all else fails, though, there's always despicable nepotism. 

[Telgin]

I got pretty lucky about landing a corporate web dev programming job after school, mostly in that there was a local company that had job postings in the hallways of the engineering building.  I almost didn't bother applying since I figured everyone and their mother would know how to do JavaScript + MySQL + PHP programming like they asked for, but I applied anyway.

I got the job because I had something of a portfolio already, so I do strongly, strongly encourage trying to build some stuff yourself to show off.  In my case I'd written a forum, intended for personal use, using PHP and MySQL as the backend, and simple JavaScript for the frontend.  It was exactly the kind of stuff the company needed a programmer for, and by sending them a link to it hosted off of my desktop's Apache installation, I demonstrated to them that I knew:

1. How to set up Apache plus the attendant PHP language module
2. How to set up MySQL
3. How to interface PHP and MySQL
4. How to use PHP and MySQL to generate dynamic content
5. How to use simple CSS and JavaScript for the frontend

I'm certain that's what got me the job over my resume.  They interviewed other candidates that didn't have anything to show off, and were seen as more iffy as a result.  My manager doesn't even have a bachelor's degree, so clearly this company valued results more than paperwork saying you knew what you were doing.

I would strongly recommend trying to build something like that to show off.  If you want to do web development work, make a website or two to show off.  If you want to do desktop applications, build a simple program for that (can be related to a hobby, maybe, like an RPG character sheet that does calculations for you, for example).  For embedded work, build something simple with a microcontroller or Raspberry Pi.  We actually had a guy apply for a job here that built these cool LED array glasses that could be programmed to display custom images and such to others.  We didn't need electrical engineers, so he ended up in a customer support role, but anyway...

If you can find somewhere to take an internship I'd strongly recommend that too.  Experience is crucial, and even an unpaid internship (which are pretty rare in this field from what I've seen) would give you a leg up.

As for the job itself, I've said before that I learned more in a few weeks on the job than I did in 4 years of undergraduate school.  That's not really true, but it does reflect the shift in priorities and the way you approach things.  It varies tremendously from company to company, but here at least we don't have code reviews, so nobody cares what data structures or algorithms you use, or if your code is the most efficient can be, or even if it's pretty.  It just needs to work and deliver results, which usually makes the real problems you're solving deciding what technologies to apply to the problem and how.

For example, I recently had to write a script to email a spreadsheet of people who had upgraded internet service to a specific email address.  That involved finding a Node.js library for generating CSV files and reading up on how it worked.  I then had to write code to pull the data from our database and convert it to the format the library needed, which involved using another library that abstracts the MongoDB queries.  Lastly, once I had the CSV generated, I had to use yet another library for interfacing with Mandrill, which is an email service, to send the email over their REST API.

You'll constantly be learning new libraries, APIs and technologies.

Oh, and yes, it's a 9 to 5 kind of thing and there are meetings.  Usually about two a month here, but some more disciplined companies have many more.  We're laid back and management is pretty hands off, so we just get a project with specifications and left to our devices to implement it.  The biweekly meetings are just to refresh what projects everyone has on their plates.  We do have to fix bugs and unexpected things as they crop up, of course.

[Parsely]

Really good response Telgin. I enjoyed reading that.

[breadman]

I'm pretty sure I landed my first full-time programming job by being willing to work for a relatively low starting salary, on top of having maintained a PHP/MySQL website that I could show off, and mentioning Vim as my preferred editor.  A Physics degree certainly didn't hurt.

The main things CS degrees have historically failed to teach include version control systems and how to read legacy code.  Contributing to open-source projects, even simple bugfixes, will help tremendously.  Particularly if you include test cases to ensure that the bug doesn't crop up again.

I also find myself setting up servers frequently, often for local development but occasionally for production.  Familiarity with Linux helps there; not only using it, but installing, configuring, and sometimes compiling packages.

Meanwhile, I've discovered that I like working in small companies, where I can basically own a full project and make people happy with small changes deployed quickly.  Relatively few official meetings, but plenty of unofficial brainstorming and lots of different responsibilities.

[MorleyDev]

It may be worth looking to see if there are any software developer meet-ups in the area around you. Software Developers who go to those tend to both enjoy their jobs (They're going to an event all about it it in their spare time after all) and are slightly more likely to work at companies that, in general, aren't hellish cubicle nightmares of despair fuelled by children's tears and a crippling fear of technologies newer than 2005.

Students are typically welcome at the ones I go to, and it's even a good networking chance for students to learn about the development world in their local area and what companies are hiring and for what. And since you met them at an event and talked to them, and hopefully they didn't hate you, that gives you an immediate leg-up over competing applications.

Me? I got lucky. My Computing teacher at college went on maternity leave, so the college brought in a local real-world programmer to replace her for the rest of the year. He recommended me to a company in the area when I was looking for a work placement (If you can, definitely do a placement year) and I learnt the ways of working in the real world, as well as things like Agile, Unit Testing and TDD, and Continuous Integration and Continuous Deployment. My Uni actually had an optional one semester-long final-year module which covered things, lots of them don't even have that. Well, free 10 credits at least after working there.

After Uni, went into client-side web development on e-learning software. Despite being a company of the same size, it was much more corporate and had more 'long time' developers who'd, well developed what they'd describe as caution but I'd describe as a crippling fear of change (It goes past caution when it results in constantly allowing the competition to get ahead of you and being stuck in a cycle of having to play catch-up and then stagnating). But I learnt:
a) Don't work at a place like that.
b) Banks still use IE6.
c) Web development can be fun.
d) The new SPA frameworks out there are getting ever nicer to work with (Admittedly this was learnt by taking c and doing stuff in my spare time).

And then I escape that place, and found a place looking for a full-stack developer. So now I work on Microservices and SPAs. This is fun. If you can, learn both sides of the fence.

As for meetings,
First job was Agile so meant:
* 10 minute standup every morning.
* Fortnightly demo to stakeholders.
* Fortnightly retrospective on last fortnight of work.
* Fortnightly planning meeting to plan next fortnight of work.
* Review meetings anytime a major issue happened, to identity how it happened and what we can do to prevent it in the future (If something got to live, our system isn't wasn't robust enough to catch that issue. More than one person has to make a mistake so there was no real blame culture)
* Probably some other ones I'm forgetting.

Next job was working for clients, so a lot of meetings between the people working on the project and with clients over phone/internet chat. Plus a biweekly team meeting.

New job, we're in control of meetings a lot more. We set-up most of them because we want our stakeholders to be more involved in what we do. Benefits of being a small team.

Honestly? More meetings isn't bad. In my experience a 'lowly developer' will pretty much always have a manager type (Project manager or Team lead or whatever) in there with them so the more formal stuff gets taken care off

[itisnotlogical]

I actually kinda figured out how to optimize something on my own.

I'm working on my own A* for Unity, and I was seeing big pauses and memory usage on the frame a path is calculated, for a really coarse 50x50 map (the path only went over about half of that). These were hardly worst-case scenarios either.

I figured it was probably this shit:

Code: [Select]

openList = openList.OrderBy(x=>x.f).ToList();
Because the A* tutorial said "Keep your list sorted so you can just grab the first node off the list".
So, I replaced it with this:

Code: [Select]

void sortedInsert(Path_GraphNode node)
{
for(int i = 0; i < openList.Count; i++)
{
if(node.f > openList[i].f)
{
continue;
}
openList.Insert(i, node);
return;
}
}
It's insane. I created a scenario that took over half a second and 2.4MB with the old method, now it's less than a kilobyte and 2 miliseconds according to Unity's profiler.

Lesson learned: Don't just go with the first thing when you google "How to sort a list in C#". It was really really stupid in retrospect. I shouldn't be patting myself on the back for this, it was an obvious fix that should have been my first try.

[Shadowlord]

Yep. Sorting a list or array with OrderBy is spectacularly inefficient, and there's no real way to fix it other than to pretend it doesn't exist and write something non-braindead, like you did.

[DragonDePlatino]

Better yet, if you want an even faster sorting algorithm for your pathfinding, try a binary heap. It'll have O(log n) sorting time instead of O(n).

[Reelya]

Better yet, if you want an even faster sorting algorithm for your pathfinding, try a binary heap. It'll have O(log n) sorting time instead of O(n).

The trade off is that binary trees also have O(log n) insert/remove time, rather than constant time for the linear list.

So, it's going to be a bit here and there. A*'s open list is constantly growing and shrinking, so the exact saving will depend on how much time is saved by o(log n) inserts vs having to use an equal number of o(log n) removes rather than constant-time removes. That will depend on the size of n at each iteration.

[itisnotlogical]

What do o(n) and o(log n) mean? Now that it's relevant to a current project, I might have enough context to get it.

Also, something A* guides don't mention: You've got to clear out the "parents" of each node after creating a path through them. Otherwise I ended up with infinite loops when going back through the parents, which I don't understand; each node only has a reference to its parent, so if two paths ever cross then they should just overwrite rather than crossing wires. It can't be two agents trying to use the same square at the same time, either, since paths are started and finished one at a time.

[Reelya]

if something is O(n), then the average time it takes to do a calculation with n things is some multiple of n. e.g. linear search of an array or list for a specific value.

O(n^2) means that it takes n^2 time units. e.g. if you are taking 100 things and need to multiply them by another 100 things, that's 10000 calculations, or O(n^2).

O(log n) means that the time taken is proportional to log n. For example, binary search for a value, where you're halving the search space at each step.

With the logs, you don't have to specify a base either, because logs in one base are always proportional to logs in another base because of the base-change relationship:

log_bx = log_ax / log_ab

So, an algorithm with parameter "x" which is logarithmic with base-2 (binary search) is proportional to the log of "x" in any other base b (because a=2 and b is a constant). So you just need to know that the algorithm is O(log n), and some multiplier of how much time a "unit operation" cost in that base.