|
Pollyanna posted:Had a phone interview with a recruiter yesterday, and the topic of work history came up, specifically time spent at a job. My last two jobs have been 10 months and 1.5 years, in order. The recruiter said they wanted engineers to stick around for 3+ years, which is sensible, but...well, that's not what I'm used to. Well, of course -- the company would also prefer engineers to work for free, I'm sure. All that comment really needs as an answer is some vague, optimistic-sounding blather about how you'd have no problem staying at a company for a long time if it's a great fit for you. That things might go bad or you might bail for something better is well-understood.
|
#
?
May 23, 2017 17:41
|
|
|
|
| # ? May 27, 2024 22:23 |
|
|
Ploft-shell crab posted:I think copy paste > abstraction can be pretty true & I like this blog post talking about why(tef also has a blog post on this). There's a very big difference between "duplication is better than the wrong abstraction" and "duplication is better than abstraction".
|
|
#
?
May 23, 2017 17:56
|
|
|
Pollyanna posted:Had a phone interview with a recruiter yesterday, and the topic of work history came up, specifically time spent at a job. My last two jobs have been 10 months and 1.5 years, in order. The recruiter said they wanted engineers to stick around for 3+ years, which is sensible, but...well, that's not what I'm used to. Well, if you continue your trend of doubling how long you stay at each new company, you should easily stay 3+ years. So make a graph that shows this and they should be so happy. Or like fatnastic in plastic said, it's not really your job to care about what they want. I want all the students that I train to stay forever and be completely obedient (except when I want them to be creative), but I rarely get anywhere close to that. C'est la vie ¯\_(ツ)_/¯.
|
|
#
?
May 23, 2017 17:58
|
|
|
Pollyanna posted:Had a phone interview with a recruiter yesterday, and the topic of work history came up, specifically time spent at a job. My last two jobs have been 10 months and 1.5 years, in order. The recruiter said they wanted engineers to stick around for 3+ years, which is sensible, but...well, that's not what I'm used to. I'm at the point where I'm looking for a company that does custom software development so I can work on different things. I think if I could find a good place like that, I'd stick around; I'm not planning on leaving my current place unless I find this. My employment history is also kinda jumpy. It goes 1.5 years, 6 months, 1 year at current. I do think there is an explanation for it (moved cities with family after first job, and staying in this city; second job was a disaster at a big defense Co where they had nothing for me to do for first three months, etc). But I think it's also something with my personality, I just get bored and want to do new things all the time. I did just get diagnosed with ADD though, and inability to stay at one job is very common for those with ADD. 
|
|
#
?
May 23, 2017 18:04
|
|
So much can go wrong.
|
My personal experience has been places want to see stability in employment history, but I have heard of others who view sticking around somewhere for 4 or 5 years as skill-set stagnation / getting comfortable. You recognize that this is probably going to come up in interviews / screens, so as with all questions of this nature just have a really good response queued up that assuages the concern that led to asking said question and you're ahead of 90% of the market. I just had a guy last week respond to a similar question asked by my boss with "I got into a really heated argument over how to do <thing> with my previous boss", so yeah.
|
|
#
?
May 23, 2017 18:16
|
|
|
Pollyanna posted:Maybe it's my millennial nature expressing itself, but I get really nervous when I think of tying several years of my life to the whims of a single company. I can't even stay in a single apartment for a year, staying at a company for that long is like Think about it this way: There are two futures: One where you decide to stay at the same company for a while, and another where you decide to leave the company. The former is the preferable future -- it means you like the place you work at! Obviously you've got no obligation to stay for 3 years. But you should want that to be the outcome. (It's also good for personal growth to have to deal with your own code that you write a couple of years later.)
|
|
#
?
May 23, 2017 19:01
|
|
|
Two to four years is very normal. It's a yellow flag if you have a lot of jobs less than that, but it's not a deal breaker. At my last place we hired a guy who had all sub-one year experiences. He explained that he kept being hired to do coding, then being put into non-coding roles, and all he wanted to do was code. Sadly we did the same thing to him after our project got shut down, and he left.
|
|
#
?
May 23, 2017 19:43
|
|
|
I got an offer!  It's for between what I made in my first year and what I made at my second year during my ten years at my last job!  Now I get to cross my fingers that the other place I had a second-round interview at last week will get back to me with a better offer.
|
|
#
?
May 23, 2017 20:17
|
|
|
that banned technology list looks pretty reasonable? i disagree di is bad by default, but most of the rest of the things on that list are terrible
|
|
#
?
May 23, 2017 20:50
|
|
|
I guess I kinda do want a job that will last me a good few years, so as part of my getting of companies I should also be asking myself "can I see myself staying here long-term?". But that assumes I can see all the different things that factor into whether a company has promise long-term, which I don't quite feel like I have a hold on yet.
|
|
#
?
May 23, 2017 20:55
|
|
|
All you can do is the best you can. You'll get burned sometimes, and you'll learn from that experience. That's life. But in general, I wouldn't sweat trying to figure out what the best possible job is. Just try to find one that you enjoy.
|
|
#
?
May 23, 2017 21:15
|
|
|
the talent deficit posted:that banned technology list looks pretty reasonable? i disagree di is bad by default, but most of the rest of the things on that list are terrible Some of the stuff I don't know enough about to know whether a ban is reasonable, but I'd agree with you that the only one I specifically disagree with is DI, and maybe "Data operations in code instead of the database", but mainly because that's pretty vague to me and I'm not exactly sure what it means to them without more context.
|
|
#
?
May 23, 2017 21:42
|
|
|
Steve French posted:Some of the stuff I don't know enough about to know whether a ban is reasonable, but I'd agree with you that the only one I specifically disagree with is DI, and maybe "Data operations in code instead of the database", but mainly because that's pretty vague to me and I'm not exactly sure what it means to them without more context. I'm interpreting "data operations in code instead of the database" to mean "all CRUD is stored procedures and the application layer should just invokes those stored procedures to do whatever it needs to do. don't use ORM or codefirst style stuff to do database work"
|
|
#
?
May 23, 2017 23:10
|
|
|
Bruegels Fuckbooks posted:I'm interpreting "data operations in code instead of the database" to mean "all CRUD is stored procedures and the application layer should just invokes those stored procedures to do whatever it needs to do. don't use ORM or codefirst style stuff to do database work" Yeah, that is more or less correct.
|
|
#
?
May 23, 2017 23:34
|
|
|
actionfiasco posted:Yeah, that is more or less correct. IOW, a nightmare of difficult to reason about and test 'code'.
|
|
#
?
May 23, 2017 23:43
|
|
|
TooMuchAbstraction posted:All you can do is the best you can. You'll get burned sometimes, and you'll learn from that experience. That's life. "Perfect is the enemy of good."
|
|
#
?
May 24, 2017 00:00
|
|
|
Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"?
|
|
#
?
May 24, 2017 01:29
|
|
|
Good Will Hrunting posted:Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"? Maybe a little less than 50%? I think that's pretty good though. Job 1: the first two years were good, the third not so great, the fourth better and the fifth...well, I wish I'd left after year four. Grad school: Ugh. Job 2: two years mostly down the drain. It could've been good and kept hinting that it might turn that way, so I stayed, but in the end it didn't work out. Job 3: two years so far, and it's been all over the place. There have been some really good days and some really bad days, but overall it's OK. ultrafilter fucked around with this message at 01:37 on May 24, 2017 |
|
#
?
May 24, 2017 01:34
|
|
|
B-Nasty posted:IOW, a nightmare of difficult to reason about and test 'code'. My current company has a LOT of mission-critical logic in sprocs (that are themselves chains of calls to other sprocs that usually go at least 5 deep) and they're a screaming nightmare to debug most of the time. Somebody in our company's early days was really comfortable with SQL and very little else so we get this mess. I'd honestly be interested to know what stored procedures are good for these days. Is performance the only real improvement anymore, and how gargantuan a system do you have to have for it to be worth the trouble?
|
|
#
?
May 24, 2017 01:36
|
|
|
Good Will Hrunting posted:Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"? First 3 years: didn't really know what I was doing in a corporate environment, so it's hard to say how much was the job and how much was me. But I had IIRC five or six managers in those three years because of constant re-orging and managers leaving for greener pastures. On balance, probably bad. Next was a brief stint at a startup. I didn't get along with the CEO. Left that after maybe six months. Bad. Next was working at a university. This was challenging early on, because my boss was a cantankerous "personality", very stubborn, with tech knowledge that was 25 years out of date. So we had a lot of arguments. However, they were respectful arguments, with no hard feelings, and I was eventually (after two or so years) able to convince him that I generally knew what I was talking about. The problems I was working on were quite interesting. The code on the other hand was a mess of 10-15 years' worth of grad student hacking, and I was flying solo. Call this one a wash for the first couple of years, then good for the next four. Next a startup, an offshoot of the university work after the NIH cut our grant. A bit under a year, me and one coworker. Very isolating without the university environment, and the coworker a) insisted on running everything, and b) was not able to run everything. So that went poorly. Call it bad. Now: working at El Goog, and frankly it's great (so far; maybe 7-8 months' tenure). A+ would go through interviewing process again.
|
|
#
?
May 24, 2017 01:48
|
|
|
Che Delilas posted:My current company has a LOT of mission-critical logic in sprocs (that are themselves chains of calls to other sprocs that usually go at least 5 deep) and they're a screaming nightmare to debug most of the time. Somebody in our company's early days was really comfortable with SQL and very little else so we get this mess. The advantage of using stored procedures for database stuff is that the application layer of a product tends to go stale quicker than the database, and so if you need to replace your application layer (or add another one to support some other new technology), it's much easier just to make the new application layer to use the old stored procs than porting a bunch of stuff based on, say, a specific ORM. The disadvantage is that debugging and unit testing stored procedures sucks.
|
|
#
?
May 24, 2017 02:03
|
|
|
Good Will Hrunting posted:Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"? I'm coming up on year four of a job that was rough in the beginning, got better in the middle, and is awful now to the point where I fantasize about losing my job daily.
|
|
#
?
May 24, 2017 02:08
|
|
|
Years 1-3, big name defense contractor: first year or so was great, I was being paid lots of money (to me) to work on interesting things! Then I went through long stretches of not having a lot to do which is mind numbingly boring in a SCIF, plus my part of the company was spun off into a much smaller company that had serious issues*. My choices were to become an aerospace engineer or leave the company so I left. Years 4-9, well known financial company that actually isn't garbage: I went through 4 teams in 5 years, but for the most part they were all great. It wasn't a top tier software company, but there were some smart people and interesting problems and it was fairly easy to become a big fish in a small pond, which is nice for a while. I could have easily spent another 5 years there and been moderately happy, if a little sad for not pushing myself farther. Last three months, a small search engine company that rhymes with smoogle: OH GOD THE CRIPPLING IMPOSTER SYNDROME. It seems good so far though. * Fun story, shortly after I left the power went out and the company had decided that backup generators weren't a priority so they stopped maintaining them. The building I worked in had no windows and cell phones weren't allowed, so when the power went out it was pitch black. People had to crawl down the steps in total darkness to evacuate the building. A few weeks later they were all issued glow sticks for use in an emergency because the company decided that was cheaper than backup generators.
|
|
#
?
May 24, 2017 02:36
|
|
|
Che Delilas posted:I'd honestly be interested to know what stored procedures are good for these days. Is performance the only real improvement anymore, and how gargantuan a system do you have to have for it to be worth the trouble? If you have multiple applications sharing a database then putting the database-related logic in the applications basically doesn't work, but these days it's often going to be a better choice to write a microservice that the applications talk to rather than effectively embedding one in the DB.
|
|
#
?
May 24, 2017 02:51
|
|
|
Good Will Hrunting posted:Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"? Current job over the last 2 years or so is probably anywhere between 35-50% of my day actually free to work. Which is about what I need. I usually work 9-6, but more and more I just come in at 10 when our standups start. The morning is usually garbage time. I sometimes will come in early like 6:30-7 for a change of pace if I'm really locked in to what I'm working on. Mornings are usually shot between standups and our loving open office with everyone chatting just waiting for the standups to happen. Our standups happen sequentially instead of all at the same time and it just kills an entire hour. So I'm usually bombarded with questions before or after each one by other scrum teams. Then it's an hour before lunch. During this time I'm usually still helping others, answering questions, etc. I probably get started on my own until 1:30 or 2 in the afternoon and most productive between 4 and 6 when everyone else starts leaving for the day. My first job was a bit more relaxed and I was able to be really autonomous and use my time the way I wanted to. So I was able to spend a lot of time learning new things part of the day (and was encouraged to do this by my boss). The job I had in between was hell on earth. 25 hours of meetings per week. While doing development, QA and some sys admin work. It was 80-90 hours / week at times and I just burned myself out and hosed out of there.
|
|
#
?
May 24, 2017 03:04
|
|
|
Ploft-shell crab posted:I think copy paste > abstraction can be pretty true & I like this blog post talking about why(tef also has a blog post on this). The condition described is exactly the condition that inheritance and dynamic dispatch was invented to solve. The error here is not in the creation of the abstraction, but in the way case-handling was implemented. Of course there is a compelling argument that copy-paste is simpler to understand and implement and thus less error prone in the long run than the "right" object-oriented abstraction which may end up complicating things by introducing secondary abstractions such as factories or double-dispatch - however I must admit that he is *technically* correct that copy-paste is better than the worst option of the three - i.e. a poorly implemented abstraction with a tangle of special case control flow.
|
|
#
?
May 24, 2017 04:46
|
|
|
"I didn't always have enough to do" seems to be a common statement, especially in early years. Is that common? I just plain never have enough to do at work these days and it's boring.
|
|
#
?
May 24, 2017 05:21
|
|
|
Yes, it's pretty common. Part of it is that finding work for junior employees actually takes a decent amount of time from more senior people.
|
|
#
?
May 24, 2017 06:18
|
|
|
Plorkyeran posted:Yes, it's pretty common. Part of it is that finding work for junior employees actually takes a decent amount of time from more senior people. This is hellishly true... some days I do nothing but find things for students to work on, or help them work on things. It is rewarding in it's own way, but a lot more difficult than you may think.
|
|
#
?
May 24, 2017 06:36
|
|
|
Bruegels Fuckbooks posted:The advantage of using stored procedures for database stuff is that the application layer of a product tends to go stale quicker than the database, and so if you need to replace your application layer (or add another one to support some other new technology), it's much easier just to make the new application layer to use the old stored procs than porting a bunch of stuff based on, say, a specific ORM. This makes sense; I've seen the phenomenon personally. So with this in mind it becomes a design decision whether it's worth putting up with the maintenance cost of having non-trivial sprocs hanging around, for a given project.
|
|
#
?
May 24, 2017 07:34
|
|
|
Che Delilas posted:sprocs Good god I've not seen or heard the word "sprocs" for 12 years, I was just transported back to my first job out of uni which was terrible (not because of the stored procedures). Edit: since it's kinda relevant to the thread, it was terrible because it was a family owned firm where the parents were the big bosses and the two spoiled children had hands-on director positions they didn't warrant. The son was blackmailing the mother (via their work blackberries) to give him company money in cash so he could spend it on actual coke and actual hookers. They kept rejecting my recommendations to set up a password rotation policy until a disgruntled ex-employee logged into the mother's email and forwarded one of these chains to the whole company, after which it was suddenly a good and urgent idea. Jaded Burnout fucked around with this message at 08:20 on May 24, 2017 |
|
#
?
May 24, 2017 08:14
|
|
|
Steve French posted:IMO, function header comments fall into the category of "ideally, not necessary" to me. I don't fully buy the "code should be self documenting" argument, but it is most true there. Perhaps a necessary evil when working in PHP, Ruby, Python, etc, but those are classic examples of comments that can get harmfully out of date and often don't add much value (at least when you have a nice type system available to you as an alternative). The code in most functions shouldn't need to be commented, but it sometimes does, and the "if it does, it should probably be rewritten" argument is similarly missing the point, in my view: if there is a reasonable way to rewrite the code and still meet whatever constraints/objectives exist in a way where a comment is no longer appropriate, the comment was probably describing behavior of code, which I'd generally agree isn't needed to begin with. But in the sorts of scenarios I've described above, rewriting is either not an option or won't help. I work primarily in C/C++, but also bash, python, PHP, and Ruby (99% of the time for Chef.) Yes, most code should be self-documenting, I completely agree, and 99.99% of the time the code within my functions are self-documenting. My argument for function headers is this: 1) Putting a well-defined function header structure at the top of each function takes usually just a few seconds of time. 2) It lowers your bus factor. 3) It reduces the amount of time it takes for others to get up to speed with your code on larger projects. 4) You need to always update the header of the function as you refactor your code. 5) There's no real good reason to not have at least a small function header at the top of your function, even if the function is simple.
|
|
#
?
May 24, 2017 12:38
|
|
|
My first job : 6 months for a small consultant, learned a lot but the boss was awful. Then 1 year at a web startup : had a lot of fun, great colleagues, learned a lot. Then 4 years for a web agency, first 3 year were great but the last year there was a takeover from a bad boss. Should have left after year 3. Then 1 year for a e-commerce software company, was ok but my skills were stalling, I had not much to learned and when I offered to work on innovative stuff (for them like CI) they didn't want that, they just wanted me to produce code. would not rate it good. Bosses personalities were not bad. Current job : 1.5 year for a non-technology company, working on interesting project and developping my skill. I will probably just ship at the 2 year mark. I'd say maybe 66% good
|
|
#
?
May 24, 2017 12:38
|
|
|
I'm going to bet that none of you are actually writing completely self documenting code, at least not if you are doing anything with a nontrivial complexity. Your code looks obvious and clear to you because you are writing it and understand it.
|
|
#
?
May 24, 2017 12:44
|
|
|
Jose Valasquez posted:I'm going to bet that none of you are actually writing completely self documenting code, at least not if you are doing anything with a nontrivial complexity. Your code looks obvious and clear to you because you are writing it and understand it. I wish I could work on non-trivial problems, but every time people say they have them they don't.
|
|
#
?
May 24, 2017 15:11
|
|
|
I wish I could work on non-trivial problems but "the interesting problems are for the senior engineers and the junior-to-mid-level engineers aren't high level enough to do [non-bitchwork]".  Real conversation I had.
|
|
#
?
May 24, 2017 15:36
|
|
|
Jose Valasquez posted:I'm going to bet that none of you are actually writing completely self documenting code, at least not if you are doing anything with a nontrivial complexity. Your code looks obvious and clear to you because you are writing it and understand it. I worked with a team that had a "one line of code, one line of comment" rule that was fanatically enforced. I thought it was kind of tedious, but it worked well for them and they liked it. I also worked with a team that often wrote comments that were very helpful looking but false. Like, the comment would say "returns a dictionary where foo is a float between 0.0 and 10.0 inclusive" but foo would actually be a list of floats, or it would actually return an exclusive range. Or the comment would say that the passed parameter was not modified, but then it was. The function bodies were a nightmare (because the comments tell you what's going on so it's OK!). My own team mostly followed the "no comments" rule. Things that could conceptually be grouped as a library got some documentation explaining its purpose, and a couple really difficult functions got comments. Everything else, we kept the functions under 30 lines long and looked hard at function and variable names in code review. The goal was the you could jump into some function that you didn't remember, see who calls it and who it calls, and understand within a few minutes and without help. I thought it was successful. I don't think "no comments" is the best strategy, but it beats everything except "always correct comments" which takes a lot more effort to enforce.
|
|
#
?
May 24, 2017 15:54
|
|
|
Pollyanna posted:I wish I could work on non-trivial problems but "the interesting problems are for the senior engineers and the junior-to-mid-level engineers aren't high level enough to do [non-bitchwork]". Then you work for a company that is bad at mentoring junior-to-mid-level folks. They should be able to carve of small slices of the non-trivial problem to farm out to the mid-level folks, then give it a thorough code review and feedback.
|
|
#
?
May 24, 2017 16:39
|
|
|
Jose Valasquez posted:I'm going to bet that none of you are actually writing completely self documenting code, at least not if you are doing anything with a nontrivial complexity. Your code looks obvious and clear to you because you are writing it and understand it. That could very well be the case, but if my code reviewer understands the code without comments then I won't really bother putting them in.
|
|
#
?
May 24, 2017 16:40
|
|
|
|
| # ? May 27, 2024 22:23 |
|
|
Good Will Hrunting posted:Industry vets: what % of your jobs (or % of your time spent working, as I realize jobs can obviously change) would you say was "good"? Very very high. Year 1-2: Owned own ISP learned so much when you have to do everything from billing to bitching at Telco's why something called a 'hardware loopback' is preventing you from bringing up a new client. Year 3: Doubled Takehome and learned a bunch of Enterprise Software Year 4: Doubled Takehome and played EverQuest as the consulting firm didn't want me on any contract that wasn't involving said Enterprise Software Year 5-7: MMO Games. First part that would be slightly not good as the start of the environment (First 4 months?) Was highly toxic with a Manager and lead on another team making life poor for everyone else. They were both fired and it was glorious. Year 8-9: More MMO Games, didn't have a chance in hell but learned so much. Year 10: Worse job. MMO division sold to other company that merged it with a startup. Only one I'd say truely is not good. Bad leadership, pointless project. All we did was a tech demo for a monthly funding meeting to give us funding for another month where we did another tech demo. 95% turnover from the MMO division in the first 12 months includnig myself. Year 11-16: FPS: Easy work in a company going nowhere. No real direction or leadership. Year 17-21: Mobile gaming. Best set of work and challenges I've ever had. AAA+ Would do again.
|
|
#
?
May 24, 2017 17:40
|
|
