Some of the best career advice I've ever gleaned is to work on something that visibly makes money for the company. I get to do that every day at my tech company. I don't know that I could say that if I worked in a technical capacity in another industry.
9:00 - 4:30 daily hours, no nights, no weekends. Full benefits, good salary, good yearly bonus, quiet office, great people who were there to get a job done and then go home.
Had to wear a shirt and tie but that's not the worst thing in the world.
The only trouble is that finance is only in the NYC area. You can't be there if you are in the valley.
There used to be some in Chicago. Bank of America, Swiss Bank, First Chicago. Swiss Bank is now UBS and I don't know where they do their trading system development. First Chicago got absorbed by JP Morgan Chase. B of A might still do some trading development there, but I have no idea.
Back in the 90s Swiss Bank and First Chicago used NeXT for trading apps, and Swiss Bank had Symbolics machines here and there.
The skill I look for over all others is an understanding of the standard principles of software design, and principles of testing is a bonus. I want to see that the candidate is honestly interested in our language to the extent that they are familiar with the obvious pitfalls of the standard language features. Candidates who prepared by writing option pricers and passing leetcode challenges won't necessarily understand any of these, because they are simply writing functions.
I assume that anyone who got through a rigorous engineering undergrad has the mathematical preparation to perform as a quantitative developer. This won't be true for all roles, but it's true for all of the QD roles that I have contact with at BB.
If you are interested in a dev role in finance, and see requirements for basic financial knowledge, risk, etc. -- as long as the requirement isn't quite specific, such as experience pricing specific option types, pricing complex products, or with a specific product, I would just ignore it and apply. Many of these concepts are quite simple compared to what SEs are trained to model and implement, and the people on the team who need help know that.
I've seen GPU and C++ skills requested for a Pandas shop. Just apply.
I think hiring managers and HR think they will attract better candidates by adding these things, but it is counterproductive.
From what I can tell from salary surveys, we pay an entry-level dev better than many others. >150 guaranteed all-in first year, and better than that afterwards if you just do your job. Promotion path is good because modern skills are in dire need.
I left because it was my first job out of college and I wanted to see what else was out in the world. But it stays a fond memory of a solid job.
Yes, a lot of adults wear sweatshirts and hoodies now. However, if you wore a shirt and tie to a high school, they would make fun of you for dressing up like your dad. We have collectively agreed on a "grown-up" attire.
Yes.
Dressing for comfort, or to suit the physical demands of your job are valid motivations. I wore a shirt and tie at my first job (back in 1987), but within a few years, I didn't bother any more because no one else did. Nowadays, "business casual" is fine by me.
My initial reaction was to guffaw at the ridiculousness of such a statement. Expression through fashion and attire is pretty much the entire reason we dont all wear the same thing as each other every day. I feel the exact opposite as you: people who dont dress with the awareness that their appearance is a statement to the world they walk into are missing a massive opportunity to affect their day. How people treat you. How people respond to you. Etc.
But since I'm growing less cynical in my old age, I would care to learn more about your perspective if you care to share.
Which, of course, tech companies don't value at all. From what I've seen, they much prefer to hire a fresh grad over somebody with a long record of proven performance.
So, I agree that one should seek work in tech at a non-tech company.
In any case the same bank with Blockchain and big data lakes will also be working with mainframes and COBOL, so generalisations about technology aren't particularly useful when it comes to organisations that are so large.
You're a carpenter. You nail boards together to serve the business interests of the company. Even if the boards are SQL queries or ReactJS or whatever.
Companies need tech. You can bring value by making everyone's jobs better with your technology - sand off those rough edges on everyone's workflows. Demonstrate your value.
I worked in a tech startup, where everyone did everything, and where doing everything was considered high-status: it meant you were competent at everything. Or perhaps the other way round: trying to avoid any computer-related task, for whatever reason, was perceived as an admission of incompetence, therefore low-status.
(I didn't agree with that philosophy. I am humble enough to admit that I am not an expert at something, e.g. setting up printers; and lazy enough that I want to avoid such work if I can.)
I also worked in a non-tech company with sufficiently large internal software development department, where as a programmer I focused on developing software; and if any part of the technical infrastructure stopped working, I just called the internal tech support.
In my current (non-IT/software dev) workplace, the CEO and the manager pride themselves on how all our staff can do everything. We're all sold on it with the line that "..all your future employers will be amazed at how much you can do!" Unfortunately, everything we produce is second rate junk as a result of this, as we are "all responsible for quality control," and the customers pay appropriately.
It's not that it doesn't work, clearly it does for some businesses, it's just that someone has to be responsible for making sure that the product is fit to be presented to the customer, and if everyone's running around doing everything, nobody's really doing anything.
There is always something you don't know, no matter how "senior full-stack" whatever you are. And when that happens, and the company culture does not allow you to admit it, the only solution is to use google, stack exchange, download a book or two, and perhaps ask a friend -- but neither of that makes you an expert overnight (and sometimes "overnight" is literally as much time as the agile process used in your company will give you; just because someone else, who actually is an expert in that stuff, could do that in a day).
The more I know about the things I specialize at, the more I am aware that you can't reach that depth of knowledge and experience by giving three smart questions to the search engine, and reading the three resulting articles. And by analogy, I assume the same is true about some of the things I don't specialize at.
But I have kids to feed, so sometimes I just bite my tongue and produce whatever is possible within given constraints.
This company culture also leads to playing games where everyone claims to believe that of course anyone can easily do anything -- but there are tasks that everyone is trying very hard to avoid: "It's not that I couldn't do that, I am just very busy now working on some other high-priority stuff that only I can do. Perhaps John would like to take this nice and simple task?" "Uhm, I am also in the middle of, uhm, something. Perhaps Joe could do this?" Joe doesn't have a plausible excuse ready (or is not present at the moment), so he is assigned the task. The meeting ends. If anything goes wrong, it's all Joe's fault.
In long term this reinforces the status ladder within the company, because the high-status guys are in the best position to refuse the tasks outside of their field of competence (by claiming they have more important stuff to do); the low-status guys get stuck with the tasks, produce mediocre results, and that is taken as a proof that they really deserved the low status. (If they are inexperienced 20-somethings, they will quite often buy it, and feel guilty about their incompetence. Then some moment later they change job, and realize it was all actually about the company culture.)
Laptops, printers, email, document storage and so on is part of the software development team's responsibility -- so we outsource all of it, and spend a little time on it roughly every 6 months for a new system or similar.
"Hey, I can't print". "Here's the helpdesk number for the people we pay for printers". (Some people were annoyed at first, but understood when they saw the developers' salaries compared to what we paid for the "boring" services.)
And, like, literally everyone since Adam Smith and his pins.
Assessing how good people are at skill A by trying to determine how good they are at ever-so-slightly-related skill B is what led google and the rest of the valley down the ridiculous problem solving interview quest of the aughts. Take your manhole covers and suck on them!
Abstraction is a skill, one that’s difficult to assess in an hour-long interview, but one which allows me to say “I’m great at C# but I’ll call someone when the printer is broken” - because there are only so many hours in the day.
Today? At 20... "what will I be doing for a living? Hm, I did some html and copy pasted js, I WILL BE A DEVELOPER and be RICH". Went to college, learned to develop. But I don't have any foundation, web and sql is all I know, and I am sleeping with Programming patterns book under my pillow and looking at latest programming hype (silently laughing at year of nosql databases and year of blockchain, now AI, and eagerly waiting for the next silver bullet that will solve ALL our problems :D)
IT is not a different field, but the level of today knowledge IS, also the attitude.
A friend of mine is having a successful software company and he said to me once: "If I get a guy with the attitude and background we had, I will hire him even if I wont be hiring at that moment. They became so rare, that it is worth having him on a bench, just to be there when you need him".
But joke aside, what is the issue, do you disagree?
The scales I work at are more about Big O than anything. If I make a mistake that is N^2 vs Log N then I wait a week for a job to finish verses 1 hour. That is an issue. If I add on 10 min because I inefficiently use swap space it doesn't matter. I need to pay attention to the higher abstraction rather than the minute details. Sure I can fix a computer but if I do that rather than stopping a job from doing puts across regions it will cost the company 12000 dollars for each hour I am removing malware.
Honestly, people who actually know sql enough to build a decent table design are super rare these days.
As far as everything else, you're pretty spot on.
Rather, we manage peoples computers, and the environment that allows them to function. The misconception that IT is only there to fix, is because we're invisible to you when everything works as expected.
0. https://www.forbes.com/sites/jwebb/2017/05/29/british-airway...
IT is by far more lucrative in the long run. It's just the structure of RSUs and stock options that gives start-ups the illusion of relatively larger comp gains.
We all know they are following business procedure, but there will always be some unconcious tension with departments that hinder a solution (I see marketing and legal butt heads all day).
In an ideal world, IT and Devs would be on the same page - after all who will be first contact when an end user encounters an issue?
The separation of development and support makes sense from a budgeting point of view, but operationally should be intertwined (IMO).
It's entirely reasonable for a carpenter not to want a job where they just nail pieces of wood together. Not really building anything, not really using skill. Just nailing a few boards together all day.
Carpenters build houses, woodworkers build furniture. IT people reinstall operating systems, fix printers and networking issues and software engineers write software. They have a different education, different job description and different pay scales. A woodworker wouldn't make a good carpenter nor a software engineer a good IT person or vice versa.
There is absolutely nothing wrong in being an IT person or a carpenter, they're reputable jobs that put food on the table. But if your trade is being a woodworker or a software engineer you should be slightly worried if you end up being put in a carpentry or IT. Or vice versa.
Disclaimer: I'm biased because I'm a software engineer and a woodworker. I'm good at my job but I can't fix networking issues or build houses.
It's actually at the smaller companies (like startups) where you'll be expected to do that. I worked at a company with <20 people total in the entire "IT department" (encompassing all computer-related things). Even though my job title was security analyst, I was in Active Directory, I was configuring Cisco gear, I had the on-call phone for the entire department, my phone was in the helpdesk rotation, I'd be dispatched to satellite locations to troubleshoot their wireless.
In my current job as a consultant, I've worked with startups where their engineers are answering support emails and replacing their own hard drives because they don't have a helpdesk or a desktop support team.
'exDM69, I'm not arguing with/against you, just piggybacking off your distinctions to help the conversation. If you're afraid that moving from a tech company to any other enterprise will have you putting on many different hats, it's probably not true. Unless you move to a tiny company, which is true for tech companies as well. Any real enterprise company will have dedicated IT support teams and you will be reprimanded for trying to perform your own IT maintenance since that's not your job.
IT runs the network, phones, issues and fixes laptops, maybe provides servers, often is in charge of information security. May own the financial and business intelligence technologies. Unless it's a very enlightened org, this is often the "cost center" team.
Digital talks to the world in a modern way--runs the websites, blogs, social media channels, paid digital ads, etc. Often housed within a larger communications and/or marketing division. Technically a cost center but the visibility makes up for it in the eyes of executives.
Product builds the technology that makes money. This would be like the e-commerce platform, ad network, mobile apps, etc. Executives value things that make money.
Often, all three groups need developers. The tools and roles may differ, but you can be a developer in a major company without feeling "stuck in IT."
The second (making a bottom-line impact) is probably a non-issue. If it's not a tech company, that means they are likely failing to use tech fully, in places that really could benefit from it. Automate stuff that needs it, and quantify the time saved as:
(time it took before - time it takes now) * number of times each person has to do it per week * number of people * what those people get paid / what you get paid = time T you saved in a week, in terms of your own hours.
Each time you do something, add its T value to a running total. Likely an hour here, an hour there. Eventually it hits 40 and you and the managers can clearly see that your employment is paying for itself. Keep going and you're making them money.
Only by beancounters, and if you take it away and go back to paper, they'll quickly change their mind.
Good developers cost a lot no matter where they hang their hat.
Depends on the company. Where I am, IT is in charge of maintaining the computers and networks so that the software developers can develop software in and for other departments.