schedules and such

Posted by on Oct 18, 2009 in coop course | 0 comments

One little thing that I have picked up during my internship has been my preference for work schedule and work dress code.

As far as schedules go, when I was full time I pretty much only worked from 8 am until 4 pm.  Occasionally I would need to come in later or leave earlier, and that was just fine.  Sometimes I would even stay late one day so I could come in really late the next day.  This was just fine as well.  In fact, it didn’t really matter when I worked as long as I was there for my meetings, and my schedule didn’t interfere with getting work done.  I know that I would be able to do just fine at a company with a more rigid schedule, but I definitely prefer the loose system that I have now.

Now about dress codes; I think I would most prefer a completely relaxed dress code (aka jeans and t-shirt).  I can say with complete sincerity that I have had no problem with the business casual code that I have had at my internship.  Again, I think I could get used to a regular business standard dress code, but I think that I would prefer more relaxed.  This part has surprised me the most during my internship.  I used to think that I wouldn’t be able to stand not being able to just wear jeans and t-shirt to work.  Fortunately I have been able to discover that this is not the case.

———————————————————————–

P.S. for those of you subscribed to my blog, I have been writing blog posts for a coop course that I am taking.  Feel free to ignore these…

Read More

systems for systems

Posted by on Oct 11, 2009 in coop course | 0 comments

One thing that has been apparent the whole time I have been interning has been that large organizations have lots of systems.  I’m not just talking about the computers or servers, I’m talking about the methods and software used to control the interaction between individuals and groups.  There are systems for moving code from development to testing to production.  There are systems for getting access to new software or databases.  There’s a system for almost anything you can think of.

The amazing thing is that when you have a lot of people, these systems are ridiculously important.  The database administrators would be bogged down by requests if every single request was different.  They would have to interpret each request before they could even do the work.

The really interesting thing to think about is how important it is for a system to be setup correctly from the beginning.  I know that no system can be perfect from the beginning, but that first try is seriously important.  If it is really screwed up, it can take forever to get it to a good place, especially if it is not readily apparent where the problem lies.  With all the systems setup to safe-guard the other systems, it is very difficult to get something to change.  It just burns this thought in my head: a new system must be very well thought out before being implemented (this is of course assuming the system is within a large organization…)

Read More

the factory pattern

Posted by on Oct 3, 2009 in coop course | 0 comments

I made myself understand the factory pattern when I was taking Software Design during my fall 2008 semester.  That is, I understood enough to do well in the course.  Looking back I never really understood it; more importantly I didn’t see it’s usefulness.

This week I received the best explanation from my manager at work.  The best part was being able to see the real world implementation of the factory pattern.  I think the key thing that I was missing was that the factory will return an object that implements an interface, so you can have any number of implementations of the interface that will all be valid objects.  Add in some inversion of control and you have yourself an amazing dynamic system where you can drop in libraries at anytime (even runtime) and use them as though they were compiled with the system.

Read More

existing projects

Posted by on Sep 26, 2009 in coop course | 0 comments

I was recently given a task at work where I had to move an existing project from one process to a totally different process.  The fun part was that not only had I never worked with the existing project, I had never worked with the new system it was being moved to!

So I have to learn 2 new things at once to be able to complete this project.  Kinda interesting…

It definitely gets me thinking about how to make this kind of system work  better.  There’s not much I can do for this particular situation since there isn’t any pre-project work that I can do on either unknown.  It seems like it would be helpful to have worked on both systems prior to this project.  I know as a new employee I will always have to be learning new systems, but it seems like everything would work a little smoother if it was one new system per project.

Read More

double duties part duex

Posted by on Sep 19, 2009 in coop course | 0 comments

Splitting work and school so far has been alright, but I’m kind of worried about what it might mean later in the semester.

I am definitely learning a lot working at Jackson, but what happens when I have a lot going on at school?

Speaking of learning a lot, here’s a few things I have picked up so far at Jackson:

  • Programming in “the industry” is quite different from programming at school
    • A solution isn’t necessarily the right solution just because it works and is fast
    • There are standards that are in place that are kinda like unspoken rules at a secret club
  • I actually like programming in Java
    • It’s fairly similar to the languages I have been using
    • Eclipse makes learning the language much easier with autocomplete and syntax checking
  • I will never know it all, and I need to rely on others
    • I have been put on projects where I literally know nothing
    • People higher up aren’t the only ones that have good answers, many times my peers know as well
Read More