|
I think I might be a Technical Product Manager, Cloud Infrastructure soon and I’m not sure if I should be pissed or happy. I’d be the first titled TPM in a company of 6000. I’ve been doing what appears to be the job roles with a Dev title but I was just trying to not let our group flounder. I haven’t legit coded for 9 months because of this monster cloud project during an acquisition integration into a larger company soooooo (Word spaghetti title ahoyyyyyy)
|
#
?
Aug 23, 2018 02:17
|
|
|
|
| # ? May 9, 2024 22:08 |
|
|
fourwood posted:This is unironically my favorite. (Not that I've tried or would want to implement it in code. Just as a concept.) It's not that bad... code:
|
|
#
?
Aug 23, 2018 02:36
|
|
|
Hughlander posted:int i = c / 4; 
|
|
#
?
Aug 23, 2018 03:19
|
|
|
No j?
|
|
#
?
Aug 23, 2018 03:21
|
|
|
ultrafilter posted:No j? Too visually similar to i because, you know, they really care about variable names there.
|
|
#
?
Aug 23, 2018 03:55
|
|
|
ultrafilter posted:No j? j ascended bodily to Heaven.
|
|
#
?
Aug 23, 2018 05:14
|
|
|
Try muslim holidays, they use a lunar calendar that shifts by a couple weeks each year, compared to the Gregorian calendar.
|
|
#
?
Aug 23, 2018 07:14
|
|
|
Depressingly accurate.
|
|
#
?
Aug 23, 2018 15:17
|
|
|
BaronVonVaderham posted:Depressingly accurate. goddamn those pictures are loving spot-on
|
|
#
?
Aug 23, 2018 16:12
|
|
|
I...I can't laugh at that.
|
|
#
?
Aug 23, 2018 17:34
|
|
|
Hey, I'm just the messenger I copy pasted from https://github.com/psholtz/C-Language/blob/master/Stanford-CS106B/Course-Reader/Chapter-02/Exercise-08/Easter.cpp
|
|
#
?
Aug 23, 2018 22:17
|
|
|
Carbon dioxide posted:Try muslim holidays, they use a lunar calendar that shifts by a couple weeks each year, compared to the Gregorian calendar. So do the Jews, AFAIK, which is where the Easter problem comes from. quote:The First Council of Nicaea (325) established two rules, independence of the Jewish calendar and worldwide uniformity, which were the only rules for Easter explicitly laid down by the council. No details for the computation were specified; these were worked out in practice, a process that took centuries and generated a number of controversies. It has come to be the first Sunday after the ecclesiastical full moon that occurs on or soonest after 21 March,[10] but calculations vary.
|
|
#
?
Aug 23, 2018 22:48
|
|
|
darthbob88 posted:So do the Jews, AFAIK, which is where the Easter problem comes from. The Jewish calendar is a lunar calendar, but they have an extra month every few years to keep it roughly aligned with the solar calendar.
|
|
#
?
Aug 24, 2018 00:15
|
|
|
Saw a Pepe av on SO for the first time today  Suppose it was a matter of time
|
|
#
?
Aug 24, 2018 15:38
|
|
|
Question for y’all. I’m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There’s been a lot of talk about how poorly my company’s code is documented and understood because the code base is so large. I figured one thing I could do to at least help a little is start putting way more comments in to explain the little bits I’ve touched so far (I’ve got one bigger PR in the works at the moment). Right now the code base is very hit or miss with it. Or is this a giant mistake? If not, any preferred type of comments or styles?
|
|
#
?
Aug 24, 2018 15:54
|
|
|
Shirec posted:Question for y’all. I’m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There’s been a lot of talk about how poorly my company’s code is documented and understood because the code base is so large. Documentation is almost always a good thing, though I would recommend against signing your Just bear in mind that there can be too much of a good thing, and don't over comment your code. You should generally document each public method, along with any methods whose operation may be confusing or counter intuitive, but you don't need to document helper functions etc. if they're straightforward. Google's style guides have a couple of brief comments about how to format your documentation for your language, which might be nice to think on. If there's a standardized style guide at your codebase (and there should be!) defer to that instead. One thing that might help is creating a PR for documenting a particularly bad section of code, if it took you quite a bit of staring or you needed to ask someone. While you're in there, you might be able to clean it up too!
|
|
#
?
Aug 24, 2018 16:07
|
|
|
In my experience, confusing code is confusing usually as a result of some arcane business rule people have forgotten about. It should be easy enough to follow what the code is doing, but the why of it can be pretty elusive.Munkeymon posted:Saw a Pepe av on SO for the first time today Does SO have a rule about bringing up politics? Could probably report that user if they do.
|
|
#
?
Aug 24, 2018 16:19
|
|
|
Clanpot Shake posted:In my experience, confusing code is confusing usually as a result of some arcane business rule people have forgotten about. It should be easy enough to follow what the code is doing, but the why of it can be pretty elusive. Not to mention that the thing is copyrighted and the author doesn't allow those idiots to use it. That alone is probably ban-worthy.
|
|
#
?
Aug 24, 2018 16:37
|
|
|
Shirec posted:Question for y’all. I’m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There’s been a lot of talk about how poorly my company’s code is documented and understood because the code base is so large. I'm a big proponent of self-documenting code because I'm a java programmer and we look favourably on ThisMethodDoesSomeThingsAndThenReturnsAVariableOfTypeN names. However, that doesn't always work, and so my general rule is that if the meaning of the code isn't immediately evident, add some comments. Usually it's just describing a not immediately obvious operation or breaking down a functional method chain. When it's a full method that's behaviour isn't super obvious at first, I'll write a block comment giving an overview and try to add line comments at critical steps. I almost always add javadoc to any new interface methods.
|
|
#
?
Aug 24, 2018 18:54
|
|
|
Shirec posted:Question for y’all. I’m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There’s been a lot of talk about how poorly my company’s code is documented and understood because the code base is so large. I try to avoid writing code comments where possible. My observation is that if I'm looking at a heavily commented code review, there is a decent chance that the code is bad. Exceptions to this are inline links to external documentation that describes the overall technical design if interesting, as well as non-technical documentation that describes the business process the code is modelling. If these documents sound like they'd be useful but they don't exist, write them in collaboration with whoever knows the business goal! If you have nowhere to put them, like a wiki or whatever which non-devs can read, stand one up. Imo to improve your code, get your team to: 1. Emphasise writing testable code. 2. Don't hard code dependencies. 3. Write tons of tests. 4. Keep things (classes, functions, modules, whatever) small. 5. Don't have long lived development branches. 6. Continuously deploy everything with good infrastructure to make deployment and rollback dirt simple. 7. Have excellent monitoring.
|
|
#
?
Aug 24, 2018 20:28
|
|
|
If you feel like writing a comment to make things clearer, ask yourself if a better named variable or function would do the same. Or extracting a variable or function and giving it a name.
|
|
#
?
Aug 24, 2018 23:25
|
|
|
smackfu posted:If you feel like writing a comment to make things clearer, ask yourself if a better named variable or function would do the same. Or extracting a variable or function and giving it a name. Ding ding ding, we have a winner. Not always the best choice, but should be the first choice.
|
|
#
?
Aug 24, 2018 23:29
|
|
|
A reduced scope by making the functional unit smaller can often clarify by reducing the complexity of the surrounding context as much or more than literally changing the name, often with other beneficial effects.
|
|
#
?
Aug 24, 2018 23:38
|
|
|
return0 posted:A reduced scope by making the functional unit smaller can often clarify by reducing the complexity of the surrounding context as much or more than literally changing the name, often with other beneficial effects. Smaller functions, more tests.
|
|
#
?
Aug 24, 2018 23:43
|
|
|
Shirec posted:Question for y’all. I’m looking to develop better coding habits and also find a way to distinguish myself from the pack while also helping others (easy right?). There’s been a lot of talk about how poorly my company’s code is documented and understood because the code base is so large. Definitely run this past someone more senior. If one of our juniors started doing this we'd ask them why they were writing code that needed commenting.
|
|
#
?
Aug 25, 2018 00:13
|
|
|
raminasi posted:Definitely run this past someone more senior. If one of our juniors started doing this we'd ask them why they were writing code that needed commenting. so this is exactly what I ended up doing (cause yeah, I'm not gonna go against norms haha) and he gave me some good direction. He's trying to get more readme type documentation for higher level stuff created (and I was working on something with one that had changed slightly so I was able to update it at the very least) but he wasn't opposed to method explainer @returns type stuff either so that's a plus. return0 posted:I try to avoid writing code comments where possible. My observation is that if I'm looking at a heavily commented code review, there is a decent chance that the code is bad. We're like 6/7 of this I think, it's mainly just the codebase is so loving gigantic and because a lot of what we do is done because of compliance or legal reasons, it gets really complex and tricky. Thanks y'all! Food to chew on. I'm anxious to prove myself (when I should probably just chill)
|
|
#
?
Aug 25, 2018 00:28
|
|
|
Sounds like you're doing fine and shouldn't worry.
|
|
#
?
Aug 25, 2018 05:16
|
|
|
Any idiot with basic literacy in a programming language can work backwards to the "what" of your algorithm. Document why this dumb thing exists in the first place
|
|
#
?
Aug 25, 2018 06:15
|
|
|
Do please leave sufficient documentation for your API; at a minimum please annotate your method declarations with a docblock. Then I don’t have to waste time working back to the “what” of your method.
|
|
#
?
Aug 25, 2018 21:17
|
|
|
Vulture Culture posted:Any idiot with basic literacy in a programming language can work backwards to the "what" of your algorithm. Document why this dumb thing exists in the first place And possibly also why you're not doing it some other way.
|
|
#
?
Aug 25, 2018 23:18
|
|
|
Gonna be part of the interviewing process for a potential team lead. Being on the other side feels very strange.
|
|
#
?
Aug 27, 2018 15:38
|
|
|
Woodsy Owl posted:at a minimum please annotate your method declarations with a docblock. Then I don’t have to waste time working back to the “what” of your method. If the arguments are perfectly obvious (e.g. int percent as the only argument of setVolume) skip this unless there's unexpected behavior (passing 0 requires you do extra work to re-enable the sound system later on, etc.) That said, if you're not sure, better to err on the side of over documenting.
|
|
#
?
Aug 27, 2018 15:48
|
|
|
The problem I have found with documentation, especially over documentation, is that too is part of the codebase that needs to be maintained. Except it is code that is not covered by tests and can thus be out of date without you knowing.
|
|
#
?
Aug 27, 2018 18:07
|
|
|
Back at a previous job, we had this giant pile of scheduled cron jobs that each were deployed separately, leading to nightmare scenarios over and over where it looked like something was corrupting the database and it turned out some ancient cron was still out there, being an idiot. So we developers, along with DevOps, proposed switching to deploy all the cron jobs at once, with every release. The QA Manager flipped out, saying they didn't have the resources to test every cron every release and demanded we provide QA with documentation of what every cron did. So I made that documentation. Not via a wiki article, but via a @Cron annotation that required a description of what the job did. Don't have the annotation and nobody noticed during code review? An automated test yells at you. I even made a page on an internal web service that listed all the crons, when they ran, whether they were tagged "one-off" and forgotten about, etc. QA probably looked at it once. At the same job, a customer was hounding us for ages about wanting a new API endpoint. The existing endpoints had all been documented in a wiki that was, you guessed it, hopelessly out of date. I made the new endpoint barf out its description, allowed actions, and usage notes by default. I also made unit tests that covered all the pre- and postconditions we were willing to guarantee. I even made a final unit test that verified all the actions were covered by other tests. Then I told my PO, "If the customer ever actually uses this API and wants to see the documentation, send them the unit test and tell them we're guaranteeing exactly that." The customer never hit that new API endpoint or asked for any more information. Lesson learned: Even minimal documentation is a good way to shut people up.
|
|
#
?
Aug 27, 2018 18:29
|
|
|
Volmarias posted:That said, if you're not sure, better to err on the side of over documenting. This is annoying when (especially junior) devs write a bunch of comments that are brittle and then I feel bad telling them to remove their comments, because: Keetron posted:The problem I have found with documentation, especially over documentation, is that too is part of the codebase that needs to be maintained. Except it is code that is not covered by tests and can thus be out of date without you knowing.
|
|
#
?
Aug 27, 2018 21:10
|
|
|
I've often requested changes to PRs due to a failure to update documentation. It should be considered part of the code review checklist.
|
|
#
?
Aug 27, 2018 21:18
|
|
|
Pollyanna posted:Gonna be part of the interviewing process for a potential team lead. Being on the other side feels very strange. Get ready to be surprised at the number of people who've been in the industry for decades but can't even manage to pseudocode out FizzBuzz.
|
|
#
?
Aug 28, 2018 00:26
|
|
|
MisterZimbu posted:Get ready to be surprised at the number of people who've been in the industry for decades but can't even manage to pseudocode out FizzBuzz. I'd hope a short phone/skype screen or little programming homework would filter those people out before you waste dev time with actual candidate interviews.
|
|
#
?
Aug 28, 2018 00:54
|
|
|
MisterZimbu posted:Get ready to be surprised at the number of people who've been in the industry for decades but can't even manage to pseudocode out FizzBuzz. a foolish pianist posted:I'd hope a short phone/skype screen or little programming homework would filter those people out before you waste dev time with actual candidate interviews. One of the senior devs today was posting in our chat about an interview she was holding and apparently a guy with 3 years experience couldn't manage what was a pretty simple coding test. I felt bad for him, but man, from what she was talking about, he could barely figure out how to do anything. He couldn't even figure out how to do the "Give me 1 through x results" part because he kept asking how could he know what x was.
|
|
#
?
Aug 28, 2018 01:45
|
|
|
|
| # ? May 9, 2024 22:08 |
|
|
MisterZimbu posted:Get ready to be surprised at the number of people who've been in the industry for decades but can't even manage to pseudocode out FizzBuzz. There's a correlation between the quality of candidates and what your published pay scale is, I've found, but yes also mostly this. Shirec posted:One of the senior devs today was posting in our chat about an interview she was holding and apparently a guy with 3 years experience couldn't manage what was a pretty simple coding test. I felt bad for him, but man, from what she was talking about, he could barely figure out how to do anything. He couldn't even figure out how to do the "Give me 1 through x results" part because he kept asking how could he know what x was. There's plenty more where that came from. The best way to cure imposter syndrome is to do phone screens.
|
|
#
?
Aug 28, 2018 02:29
|
|