What is a day in a life for a Computer Programmer
I am potentially getting a degree in either Computer Science or Computer Engineering and I want to know what my carrer options are after I get a degree. #computer-science #computer-software #computer #computer-hardware
3 answers
Joanne’s Answer
To me, there appears to be different branches of opportunities you can pursue:
- Data .. if you know how to manipulate data, there's an abundance of opportunity developing here
- Coding .. know the most current (hot) languages
- Security .. this is another HOT growth opportunity
- Operations .. this isn't as hot as it used to be unless you work for one of the companies that produce the cloud (i.e. Amazon, Microsoft)
Experience at an intern level should help you identify what you do / don't like about certain computer disciplines.
syed’s Answer
Important Career Projects
Here are chronological highlights of my SAS career, I feel very fortunate to have had the opportunity to do this level of work, beginning so early in my career and most importantly to have worked alongside so many talented and helpful technical professionals who have contributed greatly to my personal and professional development.
Refactoring the original SASIO Assembly code written by Anthony James Barr, who developed most of the original SAS core supervisor. In my opinion, Barr is a great example of the best of the “old-school” systems software craftsmen. Unraveling his hand-optimized, sparsely commented assembly code was itself an edcation in Systems Programming.
Writing the first version of PROC OPERATE in Assembly language, the ‘operators console’ for the first version of the SAS Share Server.
Being tasked as the architect/principal developer of the Version 6 MVA Data Library for the mainframe host. This was basically designing a file system and very advanced device driver. Most of the filesystem was written in C but the original dynamic DASD driver was written entirely in Assembly language. This project spanned an over three year period and included months of basic research.
Writing a load module comparator utility in assembly language. This required an intimate knowledge of IBM mainframe load module internals.
Working on machine code generation for the SAS Data Step compiler and also helping to design optimized code generation for cross-architecture transcoding. This is used to quickly translate various floating point formats and integers between different machine architectures during network communications between them. Language used: C and IBM Mainframe Machine Code.
Designing and programming the SAS Item Object Store, a lightweight, small footprint "filesystem in a file” that provides both the stored template and output backing store for the Output Delivery System (ODS) in Base SAS. Language used: C.
Getting to spend 18 months doing basic research for security technology in Base SAS. During this time I met and learned from many luminares in Computer Security, including Prof. Ravi Sandhu and Bob Blakley.
Spending 13 years working on the authorization subsystem and related components in the SAS Metadata Server. This included a considerable amount of R&D that led to being co-inventor on four United States patents.
Matthew’s Answer
That's an interesting question - I think it varies greatly from company to company. Most engineers are expected to be able to adapt and do what it takes to get the job done and this typically also changes depending on the size of the company.
When I worked at a startup and small companies, we worked across different functions (backend/frontend/release) and learned new things on the job to get things done.
In bigger companies, the roles become more specialized and you get to focus on a specific niche. For example, as a mobile engineer I was able to concentrate solely on building features and we worked with other engineers to get things built on the backend.
This also changes depending on how user-facing your role is. For instance, as a product engineer, I mostly focused on features that users would see and interact with but someone working on infrastructure would build features for other engineers in the company.
In my specific experience, product engineers are responsible for scoping and defining the timeline for various features, work in a team to allocate and collaborate on smaller pieces, work with product designers to iterate and define how things look and work, work with data science to figure how we can measure if we're doing well (or not), work with user research/content strategy/marketing to figure out how to tell users about new features.
Matthew recommends the following next steps: